System and methods for delivering targeted marketing offers to consumers via a distributed architecture system

ABSTRACT

A system and methods for delivering targeted marketing offers to consumers during a session with an online (web-based) Internet portal, particularly suitable for online banking portals of financial institutions. An offer management system receives information corresponding to an advertising campaign of an advertiser corresponding to terms of a targeted marketing offer to be provided to a consumer accessing the online portal, and provides advertising campaign data corresponding to the targeted marketing offer and to an offer-triggering event to an offer placement system. An offer placement system receives the advertising campaign data, determines the occurrence of the offer-triggering event by a consumer during an online session with the online portal, and delivers information corresponding to the targeted marketing offer to the consumer. In response to the offer-triggering event, such as display of a list of transactions, the predetermined targeted marketing offer is delivered to the consumer during the online session.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation application of U.S. patentapplication Ser. No. 13/390,186, filed Aug. 19, 2013, entitled “SYSTEMAND METHODS FOR DELIVERING TARGETED MARKETING OFFERS TO CONSUMERS VIA ANONLINE PORTAL,” which is a continuation application of U.S. patentapplication Ser. No. 12/486,131, filed Jun. 17, 2009, entitled “SYSTEMAND METHODS FOR DELIVERING TARGETED MARKETING OFFERS TO CONSUMERS VIA ANONLINE PORTAL,” now U.S. Pat. No. 8,515,810, which claims benefit under35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 61/108,332,filed Oct. 24, 2008, and entitled “System and Methods for ProvidingTargeted Marketing Offers to Consumers Via an Online Banking Portal”,the abovementioned applications are incorporated herein by reference asif set forth herein in their entireties.

TECHNICAL FIELD

The present systems and methods relate generally to electronic,computer-based targeted marketing systems, and more particularly tosystems and methods for providing targeting marketing offers toconsumers using financial services type online systems such as onlinebanking portals.

BACKGROUND

Online financial services provided by financial institutions such asbanks, credit unions, savings & loans, and brokerage institutions arebecoming increasingly popular among consumers as a way to effectivelymanage their finances. Many people use such services to monitor theirbank accounts and cash holdings, securities accounts, savings accounts,and so forth, and utilize financial-institution-provided online billpayment or check writing services. Generally, these online financialservices are Internet-accessible via financial institution websites orweb pages, including as viewed via mobile devices. As referred toherein, such online financial services type online systems will bereferred to as “financial institution portals” or “banking portals,”although other terms may apply to such services by different types ofinstitutions.

In a traditional financial institution portal, users are typicallyprovided with a listing of their accounts, and a further sub-listing oftheir recent transactions associated with those accounts. Eachtransaction will often include the date of the purchase or transaction,the amount of the transaction, the form in which the transactionoccurred (i.e., check, credit card, etc.), and the retailer, serviceprovider, or other establishment with which the transaction occurred.Based on the details available with each transaction, as well as theease of use of most online banking portals, many consumers rely heavilyon these portals to manage their finances and investments, stay on topof budgets, pay bills, and track their purchases. Additionally, with theadvent and increased use of mobile devices (e.g., cell phones, smartphones, PDAs, etc.), consumers have constant access to their onlineservices and accounts.

In order to provide detailed and up-to-date information regardingtransactions, purchases, and accounts to portal users, banks and otherfinancial service providers must keep thorough records of thosetransactions, and employ highly-sophisticated operational systems tomaintain and organize such information. Accordingly, banking systems canprovide a rich intelligence about the purchasing habits and propensitiesof consumers. It would be highly beneficial to most advertisers to haveaccess to such detailed purchase information; however, due to strictprivacy laws and regulations that limit how financial institutions canshare consumer data, advertisers have never been able to access thisvaluable information.

Certain types of targeted marketing systems are known to be in use. Theterm “targeted marketing” generally refers to systems that enable theidentification of particular classes or segments of consumers and thedelivery by advertisers of specialized targeted marketing informationand/or offers to such consumers. Consumers are often segmented intoclasses and subclasses based on age, gender, geography, socio-economicstatus, types of purchases, and other indicia. The specialized targetedmarketing information provided to these identified classes of consumerscan include special discounts on product purchases, coupons, rewardsprogram points, or other similar incentives as regards specific productsor services provided by advertisers. Generally, the more informationknown by an advertiser, the more targeted, specialized and valuableadvertisements become.

Traditionally, marketers relied on general information such as their ownhistorical sales data or common geographic data in order to targetadvertisements (in the form of mailers, television advertisements, etc.)to customers. While this type of targeted marketing does provide somebenefit over undirected, mass marketing, it is not as specialized orprecise as most advertisers would prefer. Even with the advent andwidespread use of the Internet (and Internet advertisements), targetingmarketing still does not reach the level of detail that would optimizethe effectiveness of that marketing.

The ability to target advertisements to individual consumers based oneach consumer's actual purchases would provide a highly-effective way topresent products and/or services to consumers. For example, eachconsumer could be presented with advertisements for goods and/orservices he or she regularly buys in the hopes of increasing theconsumer's purchase of those goods and/or services. Or, the consumercould receive advertisements or offers for goods and/or service that arerelated to the consumer's past purchases (e.g., if a consumer recentlypurchased a lawn mower, then ads for related goods, such as lawnfertilizer or a hedge trimmer, could be provided).

Additionally, advertisements could be presented based not on thespecific goods and/or services purchased, but on peripheral informationrelated to those purchases, such as the consumer's typical purchaseamounts (e.g., consumer buys luxury items or is more cost-conscious),the geographic location of the consumer's transactions, the types ofmerchants at which the consumer often (or rarely) shops, etc. However,because merchants and advertisers do not have access to individualconsumer purchase histories (such as the types of products purchased,dates purchased, amounts spent, specific merchants from which items werepurchased, etc.), such targeted marketing has traditionally beenunavailable.

Further, many types of offers or redemptions associated with targetedmarketing campaigns are difficult for consumers to use and problematicfor advertisers to track. For example, many consumers are unlikely touse coupons that require printing from a computer or clipping from anewspaper in order to be used. Accordingly, many consumers ignore suchcoupons and their associated advertisements.

Another issue related to traditional targeted marketing systems is thatadvertisers generally only have records as to their own sales data, andthey do not have access to information regarding how much consumersspend or how often consumers shop at competitors of the advertisers, oreven at unrelated advertisers. Such transaction data, if available,could prove invaluable for marketing and profitability purposes. As anexample, one class of consumers could be that of purchasers ofhome-delivered pizzas. An advertiser (e.g., hypothetical advertiser“Pizza Pub”) that delivers pizzas to the homes of customers may rely onpast purchases or demographic information within a community to targetmailers or television advertisements to those consumers. However, ifthat advertiser had access to information relating to existing customersof a competitor (e.g., hypothetical merchant “Pizza King”), then theadvertiser could target advertisements to the competitor's customers inthe hopes of drawing them away from the competitor. Further, theadvertiser could then analyze information about the competitor'scustomers to determine what made the customers choose the competitor'sproduct initially. Naturally, however, it is difficult for advertisersin most markets to obtain marketing intelligence about consumers oftheir competitors.

Additionally, financial institutions are always looking for ways toboost their revenue streams and increase customer loyalty. Presentationof valuable marketing offers (such as rebates or savings on goods and/orservices) to consumers that use particular financial institutionaccounts is one way to increase loyalty and entice consumers to usepayment mechanisms associated with those accounts (i.e., credit cards,bank cards, etc.). However, most banks lack the internal infrastructurenecessary to effectively integrate advertisements from third partiesinto their existing financial institution portals. If an advertisercould work with a bank to extend offers to its customers based on thebank's knowledge of what its customers purchase, while preventing theadvertiser from accessing sensitive or consumer-identifying data, thenthat information could be used to provide valuable and targetedmarketing offers to consumers that are easy for the consumers to redeem,which would in turn lead to greater profits and increased customerloyalty for all parties involved.

Therefore, there is a long-felt but unresolved need for a system ormethod that interacts seamlessly with sophisticated banking systems andonline banking portals, or other transaction-centric information portalsor data repositories, to provide targeted marketing offers andadvertisements to users of those portals, wherein such targetedmarketing is related to each user's transactions and purchases displayedat the portal, as well as the user's purchase histories and/or spendinghabits. There is a further need for a system or method that enablessimple and straightforward redemption of targeted marketing offers whilestill allowing merchants and advertisers to track the effectiveness oftheir targeted marketing campaigns. There is yet a further need for asystem or method that provides such targeted marketing to financialinstitution customers without violating privacy laws and obtainingconfidential customer information.

BRIEF SUMMARY OF THE DISCLOSURE

Briefly described, and according to one embodiment, aspects of thepresent disclosure generally relate to systems and methods for providingtargeted marketing offers to consumers via online (Internet web-based)portals, particularly online financial institution portals associatedwith banks and other financial institutions. A targeted marketing system(TMS), as described herein, enables advertisers to constructhighly-relevant advertisements and marketing offers that are displayedto consumers as those consumers access and view their online financialinstitution account portals. The offers are generally targeted tospecific types of consumers based on prior transactions or purchasesmade by the consumers, as well as patterns in those transactions,overall consumer spending habits, and other offer-triggering events.Generally, the TMS matches specific targeted marketing offers toconsumers based upon offer criteria and associated offer-triggeringevents defined by advertisers, provides matched offers to identifiedconsumers via the consumers' online portals, tracks redemptions andother data associated with the offers, facilitates payment of rewardsand redemptions to consumers based on redeemed offers, and enables avariety of other processes and functions as described in greater detailherein.

According to one aspect, the TMS includes an offer management system(OMS) and one or more offer placement systems (OPS's), wherein each OPSoperates in association or cooperation with a financial institution'sonline services system. Generally, the OMS enables creation of targetedmarketing campaigns including one or more targeted marketing offers foreventual delivery to consumers based on information received byadvertisers, transmission of campaign data to the OPS's, reporting ofmarketing data and campaign results to advertisers after offers havebeen displayed to consumers, collecting redemption funds fromadvertisers based on redeemed offers and distributing those funds tofinancial institutions, and other processes described in greater detailherein. Generally, operations of an OPS include matching receivedcampaign data from the OMS with de-identified consumer transaction datareceived from financial institutions, injecting or merging targetedmarketing offers into financial institution portals, sending targetedmarketing campaign performance data to the OMS, organizing andtransmitting redemption data to financial institutions based on offerredemptions paid to consumers, and other processes described in greaterdetail herein.

These and other aspects, features, and benefits of the claimedinvention(s) will become apparent from the following detailed writtendescription of the preferred embodiments and aspects taken inconjunction with the following drawings, although variations andmodifications thereto may be effected without departing from the spiritand scope of the novel concepts of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate one or more embodiments and/oraspects of the disclosure and, together with the written description,serve to explain the principles of the disclosure. Wherever possible,the same reference numbers are used throughout the drawings to refer tothe same or like elements of an embodiment, and wherein:

FIG. 1 illustrates a high-level lifecycle of an exemplary consumertransaction, associated marketing offer, and redemption of that offeraccording to one embodiment of a targeted marketing system (TMS)constructed in accordance with the present disclosure and certainaspects of the inventions.

FIG. 2 illustrates a high-level overview of one embodiment of a targetedmarketing system (TMS) and its associated environment, according to oneaspect of the disclosure.

FIG. 3 shows one embodiment of a system architecture for a targetedmarketing system (TMS) according to an aspect of the disclosure.

FIG. 4 is a flowchart illustrating the overall processes and functionsperformed by the offer management system (OMS) according to oneembodiment of the present targeted marketing system (TMS).

FIG. 5 is a flowchart illustrating one embodiment of a merchantidentification process.

FIG. 6 is an exemplary merchant identification table illustrating datautilized to categorize and identify merchant names within an embodimentof the targeted marketing system (TMS).

FIG. 7 is an exemplary validated merchant table illustrating dataassociated with merchant names deemed validly identified and thusavailable for reference in matching consumer transactions to campaigndata according to one embodiment of the targeted marketing system (TMS).

FIG. 8 is a flowchart illustrating the campaign generation process fromthe perspective of an advertiser according to an embodiment of thepresent targeted marketing system (TMS).

FIG. 9 is an exemplary screen shot of a graphical user interface (GUI)associated with an embodiment of the offer management system (OMS)advertiser portal.

FIG. 10 is a flowchart is illustrating one embodiment of the campaigngeneration process from the perspective of the targeted marketing system(TMS).

FIG. 11 is an exemplary campaign table illustrating advertiser-entered,campaign-related data received during campaign generation.

FIG. 12 is an exemplary segment table illustrating advertiser-entered,segment-related data received during campaign generation.

FIG. 13 is an exemplary offer table illustrating advertiser-entered,offer-related data received during campaign generation.

FIG. 14 is a flowchart illustrating the overall processes and functionsperformed by the offer placement system (OPS) according to oneembodiment of the present targeted marketing system (TMS).

FIG. 15 is a flowchart illustrating one embodiment of the matchingprocess for matching targeted marketing offers (TMOs) to consumeroffer-qualifying purchases (OQPs).

FIG. 16 is an exemplary consumer transaction table illustrating consumertransactions recorded by a financial institution and stored within afinancial institution database.

FIG. 17 is an exemplary de-identified consumer transaction tableillustrating de-identified consumer transactions recorded by a financialinstitution.

FIG. 18 is an exemplary matched offer table illustrating identifiersassociated with matched transactions and offers as a result of thematching process shown in FIG. 15.

FIG. 19, consisting of FIG. 19A and 19B, illustrates a process forinjecting or merging matched offers into a display from an onlineportal, where FIG. 19A is a flowchart illustrating an embodiment of ageneralized process for injecting or merging matched offers, and FIG.19B is a sequence diagram illustrating the sequence of steps associatedwith injecting matched offers into consumer financial institutionportals via a document object model (DOM) injection process according toone embodiment of the targeted marketing system (TMS).

FIG. 20 illustrates an exemplary screen shot of a graphical userinterface (GUI) associated with a typical exemplary consumer financialinstitution portal prior to injection of one or more targeted marketingoffers (TMOs) into the portal.

FIG. 21 illustrates an exemplary screen shot of a graphical userinterface (GUI) associated with a consumer financial institution portalor display with exemplary targeted marketing offers (TMOs) displayedtherein according to an embodiment of the present targeted marketingsystem (TMS).

FIG. 22 shows a block diagram illustrating the potential matching ofthree exemplary offers to consumers associated with three uniquetargeted consumer segments (TCS's) based on predefined dimensionsassociated with the segments.

FIG. 23 is a flowchart illustrating an embodiment of the redemptionprocess for determining whether one or more targeted marketing offers(TMOs) have been redeemed by a consumer, and reporting such redemptionto the respective financial institution.

FIG. 24 is an exemplary offer impression table illustrating recordedoffers that have been viewed by consumers based on consumer log-ins tofinancial institution portals.

FIG. 25 is an exemplary offer redemption table illustrating offers thathave been redeemed by consumers based on redemption-qualifying purchases(RQPs).

FIG. 26 is an exemplary campaign results table illustrating aggregatedoffer performance data (i.e., offer impressions and redemptions).

FIG. 27 illustrates an exemplary screen shot of a GUI associated with aconsumer financial institution portal with a targeted marketing offer(TMO), redemption-qualifying purchase (RQP), and a RQP icon displayedtherein according to an embodiment of the present targeted marketingsystem (TMS).

FIG. 28 illustrates an exemplary screen shot of a GUI associated with aconsumer financial institution portal displaying a representativerewards page according to an embodiment of the present targetedmarketing system (TMS).

FIG. 29 illustrates an exemplary offer management system (OMS) hardwarearchitecture upon which an embodiment of the OMS may be implemented asherein described.

FIG. 30 illustrates an exemplary offer placement system (OPS) hardwarearchitecture upon which an embodiment of the OPS may be implemented asherein described.

DETAILED DESCRIPTION

Prior to a detailed description of the disclosure, the followingdefinitions are provided as an aid to understanding the subject matterand terminology of aspects of the present systems and methods, areexemplary, and not necessarily limiting of the aspects of the systemsand methods, which are expressed in the claims. Whether or not a term iscapitalized is not considered definitive or limiting of the meaning of aterm. As used in this document, a capitalized term shall have the samemeaning as an uncapitalized term, unless the context of the usagespecifically indicates that a more restrictive meaning for thecapitalized term is intended. However, the capitalization or lackthereof within the remainder of this document is not intended to benecessarily limiting unless the context clearly indicates that suchlimitation is intended.

Definitions/Glossary

Advertiser: an entity that provides or sells goods and/or services toconsumers, and creates targeted marketing campaigns associated withthose goods and/or services as described herein.

Aggregated Consumer Transaction Data: subset of de-identified consumertransaction data derived from all stored de-identified consumertransaction data in each offer placement system (OPS) representative ofconsumers that satisfy a given targeted consumer segment (TCS).Generally collected and transmitted to the offer management system (OMS)in response to an advertiser-initiated query during generation of atargeted marketing campaign (TMC). Generally synonymous with aggregatedtransaction data, aggregated consumer transactions, aggregated consumertransaction information, and aggregated population totals.

Campaign: see targeted marketing campaign (TMC).

Campaign Data: information associated with a targeted marketing campaign(TMC), as well as its associated targeted consumer segments (TCS's) andtargeted marketing offers (TMOs). Generally includes data and/orinformation stored in the campaign table, segment table, and offertable.

Campaign Delimiting Information: information associated with a targetedmarketing campaign (TMC) that limits or defines the campaign, includingbut not limited to: a campaign name, a campaign theme, a campaign startdate, a campaign end date, etc. Generally synonymous with campaigncriteria.

Campaign Performance Data: information associated with consumerinteraction (i.e., results or performance) of a targeted marketingcampaign (TMC). Generally includes data and/or information stored in theoffer redemption table, offer impression table, and campaign resultstable. Generally synonymous with campaign results data and performancedata.

Campaign Results Table: a data table or file in the targeted marketingsystem (TMS) associating information relating to the performance(results) of one or more targeted marketing campaigns (TMCs) andassociated offers, including but not limited to: an offer identifier(ID), aggregated offer impressions, aggregated offer redemptions, etc.

Campaign Table: a data table or file in the targeted marketing system(TMS) associating information relating to one or more targeted marketingcampaigns (TMCs) conducted by a particular advertiser (or merchant),including but not limited to: a campaign identifier (ID), merchant oradvertiser identifier (ID), an author identifier (ID), a campaign startdate, a campaign end date, etc.

Competitor: an entity that provides or sells competing or related goodsand/or services to those of a merchant. Generally synonymous withmerchant and advertiser competitor.

Consumer: an entity (individual, business, etc.) that holds at least oneaccount with one or more financial institutions, and completestransactions and purchases with advertisers and merchants. According toaspects of the invention(s), based on completed transactions or otheroffer-triggering events (OTEs), a consumer becomes eligible to receiveone or more targeted marketing offers (TMOs) via the consumer's onlinefinancial institution portal.

Consumer Transaction Table: a data table or file stored and retainedwithin a financial institution's transaction system/processorassociating information relating to particular consumer transactions,including but not limited to: a consumer name, a consumer identifier(ID), a consumer account identifier (ID), a transaction identifier (ID),a location identifier (ID) (e.g., zip or postal code, city, state,etc.), a merchant identifier (ID), an amount, a rewards type, etc.

De-Identified Consumer Transaction Table: a data table or file in thetargeted marketing system (TMS), and specifically retained in one ormore offer placement systems (OPS's), associating de-identifiedinformation relating to particular transactions within a financialinstitution's online banking system that may be eligible to be matchedwith a targeted marketing offer (TMO), including but not limited to: anaccount global unique identifier (GUID) that relates back to aparticular consumer or customer of the financial institution, atransaction identifier (ID), a location identifier (ID) (e.g., zip orpostal code, city, state, etc.), a merchant identifier (ID), an amount,a rewards type, etc.

De-Identified Transaction: a consumer transaction or purchase that hasbeen processed according to an internal financial institution procedureto remove specific consumer- or account-identifying information.Generally synonymous with de-identified consumer transaction.

Demilitarized Zone (DMZ): a firewall configuration for selecting ordemarcating local area networks (LANs). Computers residing behind theDMZ initiate secure outbound requests via the DMZ; computers within theDMZ in turn respond, forward, or re-issue requests out to the Internetor other public networks. Generally used in association with financialinstitution security protocols.

Dimension: a delineating category or information associated with atargeted consumer segment (TCS) that serves to narrow the population ofconsumers that may receive a targeted marketing offer (TMO) based oncriteria associated with specific consumer transactions or otheroffer-triggering events (OTEs), including but not limited to: a merchantor advertiser category (e.g., retail, entertainment, dining, etc.), amerchant or advertiser name or identifier, a transaction location (e.g.,zip or postal code, city, etc.), a spend amount, a total spend amountfor a given time period, an average spend amount for a given timeperiod, a total number of transactions in a given time period, etc.Generally synonymous with segment delimiting information or segmentcriteria.

Dynamic Resegmentation: process of automatically delivering follow-uptargeted marketing offers (TMOs) to consumers who redeem original orinitial TMOs.

Financial Institution: an entity that provides banking or otherfinancial-related services to consumers (customers) and, in connectionwith the disclosed invention(s), offers online banking capabilities toits customers, such entities including but not limited to: banks, creditunions, credit card companies, brokerage institutions, lendinginstitutions, savings & loans, etc. In order to utilize aspects of theclaimed invention(s), a financial institution will generally includeand/or operate or control a financial institution computer system thatenables the various functions of the financial institution, wherein thefinancial institution computer system includes, among other systemcomponents, a financial institution portal, a financial institutiontransaction processor, and a financial institution web server. Generallysynonymous with bank.

Financial Institution Portal: a secure and individually-accessibleonline portal (i.e., having a graphical user interface and/or othercontrols for use by consumers) that displays information related one ormore accounts held by a consumer with a respective financialinstitution. Generally, a financial institution portal isInternet-accessible via a financial institution webpage, and displaysprior financial transactions associated with the consumer's account(s),as well as targeted marketing offers (TMOs) and subsequent redemptionsof those offers. Information associated with financial institutionportals (e.g., transactions, TMOs, etc.) is also generally accessiblevia consumer mobile devices (i.e., through wireless Internetconnections, mobile banking applications, SMS alerts, etc.), emailnotifications, and other similar mechanisms. Generally synonymous withbanking portal.

Financial Institution Transaction Processor: server or processor withina financial institution that receives and stores consumer transactiondata from merchants, and, in accordance with aspects of the claimedinvention(s), de-identifies such transaction data to remove consumer-and/or account-specific information, transmits de-identified consumertransaction data to the offer placement system (OPS) for offer matchingpurposes, issues redemptions/rewards to consumers, and performs othersimilar functions as described herein. Generally synonymous withfinancial institution transaction system.

Financial Institution Web Server: a computer server within a financialinstitution for serving financial institution content, such as webpages, transaction data, targeted marketing offers (TMOs),redemptions/rewards, and other similar content to consumers via afinancial institution portal. Generally enables communication and datasharing between internal components of the financial institution (e.g.,financial institution transaction processor) and components of thetargeted marketing system (TMS). In accordance with aspects of theinvention, a financial institution web server provides and operates acorresponding and associated financial institution portal.

Identity Assurance Rating: a percentage-based measure of the likelihoodthat a given unidentified merchant name extracted from consumertransaction data is associated with or represents a known or validatedmerchant within the targeted marketing system (TMS) as a result of amerchant identification process. Generally synonymous with identityassurance score.

Impression: an occurrence or instance of a consumer logging in to his orher financial institution portal, whereby a particular targetedmarketing offer (TMO) is displayed to (and/or viewed by) the consumer.Generally synonymous with offer impression.

Matched Offer Table: a data table or file in the targeted marketingsystem (TMS) associating information relating to particular targetedmarketing offers (TMOs) that have been matched to specific consumertransactions or specific offer-triggering events (OTEs) and may bedelivered to the consumers that completed the specific transactions orOTEs, including but not limited to: a transaction identifier (ID), anoffer-triggering event identifier (ID), an offer identifier (ID), anaccount global unique identifier (GUID) of the consumer account, etc.

Merchant: an entity that provides or sells goods and/or services toconsumers. As used herein, generally comprises an entity that providesor sells competing or related goods and/or services to those of anadvertiser. Generally synonymous with competitor and advertisercompetitor.

Merchant Category: a predetermined grouping of merchants based on thespecific nature of the merchants' business(s) and/or service(s).Generally, each merchant associated with the targeted marketing system(TMS) belongs to one or more merchant categories. Merchant categoriesgenerally serve as optional dimensions used by advertisers to definetargeted consumer segments (TCS's) during generation of targetedmarketing campaigns (TMCs).

Merchant Identification Table: a data table or file in the targetedmarketing system (TMS) associating information relating to unidentifiedmerchant names which have been analyzed via the merchant identificationprocess and associated with known or validated merchants recognized bythe TMS, including but not limited to: an unidentified merchant key, anunidentified merchant name, a validated merchant key, a validatedmerchant name, a merchant category, an identity assurance rating, etc.

Offer: see targeted marketing offer (TMO).

Offer Defining Information: information associated with a targetedmarketing offer (TMO) that limits or defines the offer, including butnot limited to: an offer identifier (ID), an offer amount, an offerstart date, an offer end date, offer text, an offer image (e.g., a logoor trademark), a minimum qualifying spend amount, etc. Generallysynonymous with offer specifics, offer terms or terms of offer.

Offer Display Information: information associated with a targetedmarketing offer (TMO) that is displayed to a consumer via the consumer'sfinancial institution portal.

Offer Impression Table: a data table or file in the targeted marketingsystem (TMS) associating information indicating that a particulartargeted marketing offer (TMO) was actually delivered to (and/or viewedby) a particular consumer, including but not limited to: an offeridentifier (ID), an account global unique identifier (GUID), a date ofimpression, a time of impression, etc.

Offer Management System (OMS): component of the targeted marketingsystem (TMS) that enables creation of targeted marketing campaigns(TMCs), targeted consumer segments (TCS's), and targeted marketingoffers (TMOs), reporting of marketing data and campaign results toadvertisers, transmission of data to and receipt of data from one ormore offer placement systems (OPS's), and other similar processes asdescribed herein. Generally includes one or more databases, memories,servers, computer readable media, processors, algorithms, portals, andother similar components.

Offer Placement System (OPS): component of the targeted marketing system(TMS) that enables matching of received campaign data from the offermanagement system (OMS) with de-identified consumer transaction datafrom financial institutions, injecting or merging targeted marketingoffers into financial institution portals, organizing and transmittingredemption data to financial institutions for reimbursements toconsumers, transmission of data to and receipt of data from the OMS, andother similar processes as described herein. Generally includes one ormore databases, memories, servers, computer readable media, processors,algorithms, and other similar components.

Offer-Qualifying Purchase (OQP): a transaction or purchase by a consumerthat may be eligible (qualify) to receive a targeted marketing offer(TMO), once processed by a system constructed as described herein.Generally synonymous with offer-qualifying transaction.

Offer Redemption Payment (ORP): a value provided to a consumer orcredited to a consumer's account based on the consumer's redemption of aparticular targeted marketing offer (TMO), including but not limited to:financial payment, cash back, account credit, account points, airlinemiles, hotel points, restaurant points, and other similar incentives. Asused herein, an ORP is not necessarily a “payment” in the sense of moneyor funds, and should thus be understood as generally synonymous withreward.

Offer Redemption Table: a data table or file in the targeted marketingsystem (TMS) associating information indicating that a particulartargeted marketing offer (TMO) delivered to a particular consumer wasacted upon (i.e., redeemed), including but not limited to: an offeridentifier (ID), an account global unique identifier (GUID), a date ofredemption, a time of redemption, etc.

Offer Table: a data table or file in the targeted marketing system (TMS)associating information relating to the content of particular targetedmarketing offers (TMOs) for delivery to selected consumers, includingbut not limited to: an offer identifier (ID), a campaign identifier(ID), a segment identifier (ID), an offer amount, an offer start date,an offer end date, offer text, an offer image (e.g., a logo ortrademark), a minimum qualifying spend amount, etc.

Offer-Triggering Event (OTE): an event or series of events that, ifsatisfied, dictate that an offer or advertisement should be provided toa consumer, including but not limited to: an offer-qualifying purchase(OQP), satisfaction of a targeted consumer segment (TCS) or some othermerchant-defined criteria, conduction of an online financial institutionportal session by a consumer, etc. Generally, an offer-triggering eventcomprises satisfaction of a predefined category or set of criteriaidentifying how a consumer spends (or does not spend) money, typicallybased on each consumer's transaction history (e.g., types of merchantsat which a consumer typically shops, types of merchants at which aconsumer rarely shops, average number of transactions completed by aconsumer for a given month, average spend amount (dollar value) of aconsumer's transactions, geographic locations in which a consumertypically shops, etc.).

OMS Advertiser Portal: an online, secure, individually-accessible portal(i.e., graphical user interface) used by advertisers, advertisingagencies, and other similar entities to create targeted marketingcampaigns (TMCs), targeted consumer segments (TCS's), and targetedmarketing offers (TMOs), review previously-created campaigns, segments,and offers, review and analyze reports and statistics related toperformance of particular campaigns, conduct billing operations, andcarry out other similar tasks.

Redemption: realization of a targeted marketing offer (TMO) by aconsumer via a redemption-qualifying purchase (RQP).

Redemption-Qualifying Purchase (RQP): a transaction or purchase by aconsumer that satisfies the associated criteria of at least one targetedmarketing offer (TMO), and thereby qualifies the consumer for a reward.Generally, but not always, associated with the same account with whichthe offer-qualifying purchase (OQP) or offer-triggering event (OTE)occurred. Generally synonymous with redemption-qualifying transaction.

Reverse Proxy: a security component, often used by financial institutioncomputer systems, that provides a layer of security to each financialinstitution's local area network (LAN) in addition to the financialinstitution's firewall(s). Generally includes computers and/orprocessors acting as proxy servers to intercept, inspect, and (ifnecessary) redirect inbound and outbound communications betweencomponents on either side of the reverse proxy. Generally used inassociation with financial institution security protocols, for example,to handle Secure Sockets Layer (SSL) encryption often used between aconsumer's computer and a financial institution web server, caching ofcontent, load balancing, performance acceleration, and for other reasonsunderstood by those skilled in the art.

Segment: see targeted consumer segment (TCS).

Segment Delimiting Information: see dimension.

Segment Table: a data table or file in the targeted marking system (TMS)associating information used to identify a particular segment ofconsumers based on transactions completed by those consumers, includingbut not limited to: a segment identifier (ID), a campaign identifier(ID), a merchant or advertiser category (e.g., retail, entertainment,dining, etc.), a merchant or advertiser name or identifier (ID), atransaction location (e.g., zip or postal code, city, etc.), a spendamount, etc.

Targeted Consumer Segment (TCS): a group of consumers to which at leastone targeted marketing offer (TMO) applies based on the specifics of theoffer(s) and one or more offer-qualifying transactions oroffer-triggering events (OTEs) completed by each consumer. Generally asubset of the entire population of available consumers. Generallysynonymous with segment and market segment.

Targeted Marketing Campaign (TMC): a marketing campaign constructed byan advertiser, advertising agency, or other entity designed to generateand place advertisements in the form of targeted marketing offers (TMOs)and display such TMOs to consumers via the consumers' online financialinstitution portals. Generally includes one or more targeted consumersegments (TCS's) and one or more TMOs. Generally synonymous withcampaign.

Targeted Marketing Offer (TMO): an offer to deliver a particular reward,refund, financial payment, offer redemption payment, or other incentiveto a consumer via a system constructed as described herein, in responseto the consumer satisfying certain requirements of the offer, e.g.,purchase of goods or services in accordance with the offer, provision ofrequested information, or other required action or conditionsatisfaction. Generally, each TMO is associated with a correspondingtargeted consumer segment (TCS). As described herein, TMOs are presentedto consumers during the consumers' online banking sessions via eachconsumer's financial institution portal. Generally synonymous with offeror advertisement.

Targeted Marketing System (TMS): overall system as described herein forcreating targeted marketing campaigns, delivering those campaigns toconsumers via financial institution portals, tracking consumerredemption of marketing offers, reporting campaign results, maintainingprivacy and security amongst financial institution clients (i.e.,consumers), and performing a host of other tasks and processes asdescribed in detail herein. Generally includes an offer managementsystem (OMS), one or more offer placement systems (OPS), and otheradditional components as described herein.

Transaction Table: see consumer transaction table and de-identifiedconsumer transaction table.

Unidentified Merchant Key: a unique identifier assigned to eachunidentified merchant name within the targeted marketing system (TMS).

Unidentified Merchant Name: a merchant name extracted from consumertransaction data and transmitted to the offer management system (OMS)for identification and association with a recognized or validatedmerchant within the targeted marketing system (TMS).

Validated Merchant Key: a unique identifier assigned to each validatedmerchant name that has been associated with a recognized merchant withinthe targeted marketing system (TMS) based on completion of the merchantidentification process.

Validated Merchant Name: an accepted or recognized name (and allvalidated variations thereof) associated with a given merchant withinthe targeted marketing system (TMS). Generally, unidentified merchantnames are associated with validated merchant names upon completion ofthe merchant identification process and the attainment of an identityassurance rating above a predefined threshold rating. Generallysynonymous with cleansed merchant name.

Validated Merchant Table: a data table or file in the targeted marketingsystem (TMS) associating information relating to merchant names thathave been validated via the merchant identification process based on acalculated identity assurance rating above a predefined thresholdrating, including but not limited to: an unidentified merchant key, anunidentified merchant name, a validated merchant key, a validatedmerchant name, a merchant category, an identity assurance rating, etc.

Overview

For the purpose of promoting an understanding of the principles of thepresent disclosure, reference will now be made to the embodimentsillustrated in the drawings and specific language will be used todescribe the same. It will, nevertheless, be understood that nolimitation of the scope of the disclosure is thereby intended; anyalterations and further modifications of the described or illustratedembodiments, and any further applications of the principles of thedisclosure as illustrated therein are contemplated as would normallyoccur to one skilled in the art to which the disclosure relates. Alllimitations of scope should be determined in accordance with and asexpressed in the claims.

Aspects of the present disclosure generally relate to systems andmethods for providing targeted marketing offers to consumers via onlineportals, especially applicable but not limited to financial institutionportals. Although the description which follows is primarily directed toapplication of the claimed invention(s) to financial institutionportals, it should be understood that the invention(s) have broaderapplicability to any systems with portals that allow consumer viewing ofpredetermined information maintained by third parties on behalf of suchconsumers, especially those that relate to financial transactions,purchases, sales, or other commercial transactions that can be analyzedfor purposes of generated targeted marketing offers based on suchpredetermined information.

A targeted marketing system (TMS), as described here in context of afinancial institution portal, enables advertisers to constructhighly-relevant advertisements and marketing offers that are displayedto consumers as those consumers access and view their online financialinstitution account portals. The offers are generally targeted tospecific consumers based on prior transactions or purchases made by theconsumers, as well as patterns in those transactions and overallconsumer spending habits. However, based on aspects of embodiments ofthe TMS described in detail herein, advertisers have no knowledge ofspecific consumers nor any information relating to particular consumertransactions. Thus, embodiments of the TMS allow targeted advertising ona banking portal in a manner that protects all consumer data andprivacy, and is compliant with the highly-complex banking and financialinstitution regulatory environment.

Additionally, embodiments of the TMS, via cooperation with one or morefinancial institutions, further enable accurate and automatic redemptionor realization of offers when consumers make redemption-qualifyingpurchases. Further aspects of the present systems and methods facilitatereporting and analytics to advertisers regarding consumer interactionwith and redemption of marketing offers, aggregation of de-identifiedfinancial transaction data for advertiser use in targeted marketingcampaign creation, and a host of other functions and processes as aredescribed in detail herein.

According to one embodiment, a TMS includes an offer management system(OMS) and one or more offer placement systems (OPS's), wherein each OPSoperates in association or cooperation with a financial institution'sonline services system (i.e., online environment), including a financialinstitution transaction processor and financial institution web server,thereby providing a financial institution portal. Generally, the OMSenables creation of targeted marketing campaigns by advertisers,reporting of marketing data and campaign results to advertisers,collecting redemption funds from advertisers and distributing thosefunds to financial institutions, and other processes described ingreater detail below. Generally, operations of an OPS include matchingreceived campaign data from the OMS with de-identified consumertransaction data received from financial institutions, injecting ormerging targeted marketing offers into financial institution portals,sending targeted marketing campaign performance data to the OMS,organizing and transmitting redemption data to financial institutionsfor reimbursements to consumers, and other processes described ingreater detail below.

In one embodiment, “de-identified” transaction data (i.e., transactiondata void of any consumer- or account-specific identifying information)is sent to an OPS by a respective financial institution. Typically, atleast one OPS is in operative association with each participatingfinancial institution to allow direct communication between each OPS andits respective financial institution. Generally, the transaction data isde-identified by each financial institution according to theinstitution's own internal protocols and procedure for removing accountinformation and other consumer-identifying information. Each OPS storesthis information for subsequent offer matching. Additionally, each OPSaggregates the de-identified consumer transaction information and makessuch information available to the OMS for use in campaign creation. Whenneeded, the OMS requests and accesses this aggregated transaction dataand utilizes it during campaign creation to estimate potentialpopulations of consumers that will receive targeted marketing offersassociated with campaigns, and other similar uses. During campaigncreation, advertisers that wish to provide targeted marketing offers(TMOs) interact with an OMS advertiser portal that displays campaignspecifics, enables creation of targeted marketing segments and offers,allows advertisers to define dimensions and specific criteria associatedwith each segment and offer, etc.

Once a campaign (and its associated offers) has been created, the OMStransmits the campaign data to each OPS for merging with transactiondata and delivery to consumers. According to one embodiment, each OPS,via a predetermined matching algorithm, matches specific consumerfinancial transactions with offers that satisfy the segment dimensionsassociated with the offers. According to another embodiment, rather thanbeing matched to specific transactions, offers are matched to consumers'offer-triggering events, such as a pattern or series of transactionsthat meet a certain set of segment dimensions. After eachoffer-qualifying transaction or other offer-triggering event has beenmatched with a respective offer or offers, the offers are displayed toconsumers via each consumer's online financial institution portal. Thus,when a consumer logs in to his or her portal, he or she is presentedwith offers that are targeted to prior transactions or purchases made bythe consumer. For example, the offers may be directed at transactionsinvolving competitors of the advertiser that created the respectivemarketing campaign (although this is not always the case).

In one embodiment, a consumer redeems a targeted marketing offer bymaking a redemption-qualifying purchase (RQP) using a payment mechanism(e.g., a debit card or credit card) associated with the respectivefinancial institution account to which the offer was originally related.The RQP is subsequently recorded by the financial institution and istransmitted to the OPS associated with that institution. The OPS thenexamines each received de-identified transaction to determine if itqualifies as an RQP associated with a targeted marketing offerpreviously presented to and received by the consumer. Once verified asan RQP, the OPS records and stores the instance of the RQP (e.g., withinits respective offer redemption table, discussed below) for subsequentprocessing. For example, the OPS determines the associated reward to bepaid to the consumer by converting the reward value of the offer fromdollars (as it is typically originally entered by an advertiser withinan OMS portal when the offer is created, discussed below) to theappropriate rewards type (e.g., points, miles, etc.) associated with theconsumer account that completed the RQP. Subsequently, the OPS providesa visual indication to the consumer in the financial institution portalthat the purchase qualified for a redemption based on the previousoffer.

At predetermined time intervals (e.g., daily, weekly, monthly) orcontinuously or on request, each OPS provides notification to itsassociated financial institution as to the sum of all offer redemptionpayments (ORPs) to be credited to each consumer's account. The sum ofthe ORPs associated with each particular targeted marketing offer (TMO)or campaign is determined by each OPS and transmitted to the OMS forstorage (e.g., within its campaign results table, discussed below) andsubsequent processing. At predetermined time intervals or continuouslyor on request, advertisers issue payments to financial institutions(e.g., by depositing or transferring funds to the OMS for transmissionto each OPS for payment to financial institutions) for reimbursement ofthe ORPs yielded from their respective TMOs based on rewards issued toconsumers. After the completion of a targeted marketing campaign (orduring its operation), advertisers are able to view results andperformance data associated with the campaign via an OMS portal.

Description of Targeted Marketing System, Components, and Processes

For purposes of example and explanation of the fundamental processes andcomponents of the disclosed systems and methods, reference is made toFIG. 1, which depicts a high-level lifecycle 100 of an exemplarytransaction, an associated targeting marketing offer, and redemption ofthat offer according to one embodiment of a targeted marketing system(TMS) constructed and operated in accordance with various aspects of theclaimed invention(s). As will be understood and appreciated, the examplelifecycle shown in FIG. 1 represents merely one approach or embodimentof the present system, and other aspects (e.g., delivery and/orredemption of offers based not on singular transactions, but on a seriesor pattern of transactions) are used according to various embodiments ofthe present system.

As shown in the lifecycle 100, a process for targeted marketing offerdelivery commences with a purchase from or financial transaction with amerchant 101 (e.g., hypothetical advertiser competitor Pizza King) by aconsumer 103. As defined elsewhere herein, an “advertiser” describes anentity that creates a targeted marketing campaign associated with itsgoods and/or services, whereas a “merchant” or “advertiser competitor”is an entity that sells competing and/or related goods and/or servicesto those of the advertiser. The terms “advertiser”, “merchant”, and“advertiser competitor” are used herein for purposes of discussion andexplanation only, and, as will be understood and appreciated, are notintended to define or limit a particular class of entities. For example,an advertiser may fulfill roles as both an advertiser and a merchant,wherein the advertiser creates marketing campaigns targeted toconsumers, and is also the subject of its competitors' marketingcampaigns (and vice versa). Thus, for practical purposes, advertisersand merchants are interchangeable. For purposes of discussion and easeof reference, however, advertisers are referred to herein as those thatcreate marketing campaigns, and merchants (or advertiser competitors)are those that provide competing or related goods and/or services tothose of advertisers.

In the example shown in FIG. 1, at some point in time, an advertiser (inthis example Pizza Pub, not the merchant Pizza King 101) generates atargeted marketing campaign (TMC) associated with its goods and/orservices (block 105). In one embodiment, the campaign is created via anOMS advertiser portal within the targeted marketing system (TMS), asdescribed elsewhere herein. Generally, advertisers define campaignspecifics, such as the start and end date of a campaign, segments ofconsumers that the campaign will target (based on physical location ofconsumer purchases, spend amounts, etc.), specific offer amounts, texts,logos associated with campaign offers, and various other predeterminedcampaign criteria (discussed in greater detail below).

As shown in block 105, the exemplary campaign has been generated by anadvertiser (e.g., “Pizza Pub”), and is scheduled to run between Jun. 1,2008 and Jun. 30, 2008. Thus, any consumer transactions occurring withinthose dates may be subject to this specific campaign. The exemplarycampaign also defines a particular consumer transaction segment (i.e.,transactions occurring in California at advertiser competitor “PizzaKing” locations, wherein the transaction is for an amount greater than$25). The representative campaign shown in block 105 also includes anoffer to be presented to consumers, wherein a consumer is offered $10off the price of any purchase of $25 or more at a Pizza Pub in June, andincludes the advertiser-defined text: “Pizza Pub voted country's bestbreadsticks!”. As will be understood and appreciated, the campaigncriteria shown in block 105 are presented for illustrative purposesonly, and are in no way intended to limit the scope of campaignspecifics and dimensions available to advertisers for campaign creation.

According to one embodiment, the TMS gathers all advertiser offerscentrally, and then displays those offers with corresponding consumertransactions via a consumer's financial institution portal. In oneaspect, if a transaction, group of transactions, or otheroffer-triggering event (OTE) meets the criteria of one of the targetedmarketing offers defined in a campaign, then that offer is associatedwith the transaction, group of transactions, or OTE, and is displayed toa consumer via the consumer's banking portal (assuming there are nocompeting offers that could also apply to the transaction(s) or OTE, inwhich case a ranking algorithm may be utilized to determine whichoffer(s) are displayed). Generally, each campaign includes one or moretargeted marketing offers of which each is presented to one or moretargeted consumer segments as defined by the advertiser. As will beunderstood and appreciated, each campaign may include a plurality ofsegments and offers, depending on the given advertiser's preferences.Further, each offer and segment may include a variety of criteria ordimensions that define the scope of each.

As shown in block 107, a consumer 103 purchases a pizza (orpizza-related items) from a merchant 101 (e.g., Pizza King) of anadvertiser (e.g., Pizza Pub). The purchase is represented in block 107,which is a representation of the transaction as shown in the consumer'sconventional financial institution portal (i.e., with no offerdisplayed). The purchase shown in block 107 is a representativeoffer-qualifying purchase (OQP) 115 (discussed in greater detail below).Generally, the consumer 103 is able to view a plurality of recent, priortransactions or purchases associated with one or more of the consumer'saccounts via an interactive and scrollable webpage associated with anonline financial institution portal. As shown, the exemplary purchaseoccurred on June 2, 2008, at Pizza King, and was for the amount of$35.98. This representative and exemplary transaction is referencedthroughout this disclosure for discussion purposes.

As will be understood by one of ordinary skill in the art, when apurchase is made by a consumer via some mechanism associated with aconsumer account (e.g., credit card, debit card, paper check, etc.),that transaction is recorded by the respective financial institution andmade available for online viewing within the consumer's financialinstitution portal. The portal typically displays a plurality offinancial transactions, each transaction including transaction-specificinformation such as the transaction date, purchase amount, merchant,etc. Thus, while only one transaction is shown in block 107, it will beunderstood that many transactions are typically displayed in consumerbanking portals. Additionally, according to various embodiments of thepresent system, if a transaction qualifies for receipt of an offer, thenthe offer will be displayed in relative juxtaposition with thetransaction in the consumer's banking portal (as discussed below inassociation with block 109). Thus, the conventional portal displayrepresented by block 107 is presented for illustrative purposes only.

Still referring to FIG. 1, block 109 is a representation of theconsumer's financial institution portal with the targeted marketingoffer (TMO) 113 displayed in perceptible association or juxtapositionwith the consumer transaction that, in this example, triggered thepresentation of the offer, e.g. the offer-qualifying purchase (OQP) 115.In one embodiment of the TMS, transactions are matched with TMOs by amatching algorithm within each offer placement system (OPS) in a mannersuch that advertisers have no knowledge of specific consumers or theiraccounts that receive the TMOs (described in greater detail below). Asshown in block 109, because the consumer's transaction satisfied thecriteria (i.e., the “terms of offer” or “offer terms”) defined in thecampaign for the specific TMO 113 (i.e., purchase within the start andend date of the campaign, at Pizza King, for an amount greater than $25,etc.), the consumer 103 was presented with the respective TMO. As shown,the TMO 113 indicates that if the consumer 103 makes any purchases (viaa payment mechanism associated with the particular financial institutionaccount) at a Pizza Pub (i.e., advertiser) of greater than $25 in themonth of June, the consumer will receive $10 off of that purchase.

In an alternate embodiment, rather than displaying a TMO injuxtaposition with a specific transaction, the TMO is displayed as abanner advertisement or pop-up advertisement, or on a separate offer(s)page, or via some other similar display mechanism (see, e.g., FIG. 21).Further, some TMOs are triggered not by a single, specific transaction,but rather by an offer-triggering event (OTE), such as an accumulationof a consumer's transactions over time that satisfy a predefined segmentbased on average spend amounts at a given merchant or merchant type, orsomething similar. Accordingly, these TMOs are generally related to aconsumer's purchase history or spending habits, and not to particulartransactions, and are thus generally displayed in a consumer's financialinstitution portal.

As will be apparent, the specific and exemplary TMO 113 shown in FIG. 1is an attempt by the advertiser (i.e., Pizza Pub) to attract consumersfrom one of its competitors 101 (i.e., Pizza King). Because the consumer103 made a purchase at a Pizza King previously, the advertiser can inferthat the consumer has a propensity to buy pizzas or pizza-related items.Thus, according to one aspect, offers within embodiments of the TMS arehighly targeted because they are provided to consumers that already havean interest in the particular type or category of goods and/or servicesprovided by the advertiser, or might be interested in related goods orservices to those of a advertiser. As will be understood, however,offers do not have to be targeted to advertiser competitors, but insteadcould be targeted to consumers who already shop with a given advertiserfor purposes of increasing business volume. For example, the advertisercould reward consumers and generate loyalty by offering frequentcustomers additional incentives to shop with the advertiser. Offers mayalso be targeted to related product areas that often go hand-in-handwith the advertiser's products or services (e.g., a golf sporting goodsstore targeting offers to consumers who made purchases at a golfcourse). Or, offers may be targeted to broad categories, such asconsumers who shop at luxury stores, or consumers who rarely buy fastfood items, etc. In general, regardless of the form of the offers, theyare typically highly relevant because they are targeted based on how aconsumer already spends money.

As will be understood and appreciated, a virtually unlimited number offinancial institutions may utilize aspects of the present systems andmethods. Accordingly, in one embodiment, offer presentation and displayis customized to match the overall look and feel of each institution'sonline banking environment. As shown in block 109, the TMO 113 ispresented in perceptible association or operative juxtaposition with theprior transaction to which the TMO was matched (i.e., the offer ispresented in relative proximity to its associated transaction). As willbe understood, the offer may be displayed according to a variety ofpresentation forms, such as immediately under the prior transaction (asshown in block 109), indented under the transaction, in a contrastingtype, font, or color as compared to the transaction, etc. If the offeris matched not to a single transaction, but to an offer-triggering event(OTE), then the offer may be displayed in a more general display manner(e.g., via a pop-up or banner advertisement), although not necessarily.Regardless, when a consumer 103 logs into his or her portal, he or shewill see an offer associated with each transaction or OTE that hascriteria matching a potential offer (assuming at least one of theconsumer's transactions can be matched to an offer).

In some circumstances, the consumer 103 may be presented with multipleoffers corresponding to multiple transactions. In other circumstances,no offers will be presented because the consumer 103 made no recentpurchases or satisfied any OTEs that match offer criteria of anypotential offers. Additionally, in one embodiment, the presentation ofoffers complies with guidelines established by each financialinstitution (e.g., number of offers allowed per display page, format ofoffers, location of offers, etc.). As will be understood, while the TMO113 is shown listed in block 109 immediately underneath thecorresponding transaction, offers may be presented in any number ofways, such as by pop-up advertisements, listing of offers in a separatesection of the financial institution portal display, and via othersimilar display formats (provided that consumers are able to perceiveand subsequently redeem the offers).

Still referring to FIG. 1, according to one embodiment, if a consumer103 decides to redeem (i.e., accept or respond to) an offer as shown in109, the consumer is merely required to satisfy the offer criteria, andthe TMS instructs the financial institution to credit the offerredemption value (i.e., reward) to the consumer's account or provide thereward to the consumer via some other appropriate reward mechanism. Asshown in block 111 of the example lifecycle 100, the consumer made aredemption-qualifying purchase (RQP) 117 at an advertiser location(i.e., Pizza Pub) on Jun. 15, 2008 for $28.93. Because this purchasefell within the advertiser-defined offer criteria (i.e., in June, at aPizza Pub, greater than $25, etc.), the TMS automatically detected thetransaction as an RQP 117, and thus instructed the financial institutionto credit the consumer's account accordingly (discussed in greaterdetail below). Next to the transaction is an RQP icon 119 (shown anddiscussed in greater detail in conjunction with FIG. 27) indicating tothe consumer 103 that he or she redeemed a previously-presented TMO 113,and thus received a reward for the subject purchase.

In one embodiment, when the consumer 103 clicks on the icon 119 via acursor (i.e., “mouse”), or simply hovers the cursor over the icon (i.e.,“mouse over”), or interacts with the icon in some other understoodmanner, the financial institution portal displays information relatingto the reward received by the consumer. As will be understood andappreciated, the reward may be indicated to the consumer 103 in avariety of ways, such as via a separate line item in the financialinstitution portal, an email notification, etc. Therefore, embodimentsof the present TMS are in no way limited to use of an RQP icon 119 toindicate redemption payments or rewards.

As will be appreciated, all participatory parties benefit from use ofembodiments of the targeted marketing system. Advertisers are givenaccess to new, online marketing channels with large consumerpopulations. Embodiments of the targeted marketing system enableadvertisers to provide highly-targeted advertisements and offers toconsumers based on how those consumers already spend money. Advertisersare also provided with data and reports related to the effectiveness oftheir offers and advertising campaigns via continually-collected andrecorded offer impression and redemption data. Additionally, banks andother financial institutions benefit by being able to offer theircustomers an additional outlet to accumulate rewards currency in theform in which their account(s) are currently enrolled. Such rewardcurrencies drive customer loyalty and use of specific accounts, increaseconsumer transactions, and reduce attrition. For example, as consumersredeem offers, they build their rewards (e.g., airline miles, hotelpoints, cash back, etc.), and thus the consumers are more likely tocontinue using payment mechanisms (i.e., credit cards, debit cards,etc.) associated with the specific financial institution account.Finally, consumers benefit from embodiments of the present systems andmethods because they receive cash and rewards merely by purchasing itemsthey typically already purchase.

Referring now to FIG. 2, a high-level overview 200 is shown of oneembodiment of the targeted marketing system (TMS) 215 and its associatedenvironment. As shown, the TMS 215 includes an offer management system(OMS) 211 remotely connected (although the connection does notnecessarily have to be remote) to one or more offer placement systems(OPS) 207 via the Internet 209. Generally, the OMS 211 enables creationof targeted marketing campaigns, segments, and offers by advertisers,reporting of marketing data and campaign results to advertisers,transmission of data to and from one or more OPS's 207, and othersimilar processes described herein. Generally, the OPS 207 enablesmatching of received campaign data from the OMS 211 with de-identifiedconsumer transaction data received from financial institutions,injecting or merging targeted marketing offers into financialinstitution portals, organizing and transmitting redemption data tofinancial institutions for reimbursements to consumers, transmission ofdata to and from the OMS, and other similar processes described herein.Although the OMS 211 and OPS 207 are represented in FIG. 2 as conceptualboxes, in one embodiment, both the OMS and each OPS comprise systemcomponents including one or more databases, memories, servers, computerreadable media, processors, algorithms, portals, and other similarcomponents (see FIGS. 29-30 for further description of OMS and OPShardware).

In the embodiment shown in FIG. 2, in addition to being remotelyconnected to the OMS 211, the OPS 207 is directly connected to afinancial institution system 205 to enable direct and securecommunication of information back and forth between the OPS andfinancial institution, as the OPS is protected behind the financialinstitution's existing firewall(s). As will be understood andappreciated, the financial institution may be a bank, credit cardcompany, lending institution, savings & loan, prepaid debit company, orother similar financial institution. Additionally, although theembodiment of the TMS 215 shown in FIG. 2 includes only one OPS 207 andone financial institution system 205, other embodiments of the TMSinclude many OPS's connected to many different financial institutions.Generally, one OMS is capable of servicing a plurality of OPS's at aplurality of financial institutions. Further, according to one aspect,more than one OPS 207 is connected to each financial institution 205.For example, an embodiment of the present system may be constructed suchthat a different OPS services each different aspect of a financialinstitution's services (e.g., credit card account, bank account, moneymarket account, stock brokerage needs, web services, transactionprocesses, etc.), or synchronized OPS's may reside in multiple datacenters that serve customers to improve scalability and reliability. Forease of reference, however, the figures and discussion of the presentdisclosure are primarily directed to an exemplary system comprising onlyone financial institution 205 and one OPS 207.

Generally, most financial institutions employ a distributed architecturein which different entities within each financial institution may belocated at different physical or virtual locations, and performdifferent services and functions for the overall financial institutionsystem. Thus, the exemplary financial institution 205 shown in FIG. 1illustrates two components—a financial institution web server 219 and afinancial institution transaction processor 220. The functions of theweb server 219 generally include, among other things, serving thefinancial institution portal (and its associated web pages, data, andother content) to consumers 103. The functions of the financialinstitution transaction processor 220 include, among other things,tracking and storing consumer transactions data for subsequent use. Thefunctions of each of these illustrated components 219 and 220 and theirinteraction with various OPS components is described in greater detailthroughout this disclosure. Additionally, although most financialinstitutions include at least these two discrete components 219, 220,financial institution systems 205 are referred to generally in variousparts of this disclosure for ease of reference.

According to the embodiment shown, all information or data passingbetween the OMS 211 and the OPS 207 is processed via a reverse proxy217, typically in conjunction with (but sometimes alternatively to) ademilitarized zone (DMZ), before the data is allowed to proceed(described in greater detail below). In one embodiment, the OPS 207 isdirectly connected to the financial institution system 205 in a mannersuch that various components of the OPS operate behind the financialinstitution firewall(s) and other security protections. Accordingly, inorder to preserve the security of the overall system, ensure securecommunications (e.g. via SSL), prevent system corruption, and retainconsumer privacy, all data and information passing into or out of theOPS is processed within a reverse proxy located on the financialinstitution's web server 219 or similar equally secure means. Generally,embodiments of the reverse proxy 217 used within aspects of the presentsystem comprise computers and/or processors acting as proxy servers tointercept and inspect all inbound and outbound communications betweencomponents on either side of the reverse proxy. When the reverse proxyidentifies information being sent to or from the OMS 211 to the OPS 207,the reverse proxy directs the information via the web server 219 to theOPS over the financial institution's internal network. Typically, thereverse proxy 117 (and/or DMZ) checks file types and formats, verifiesthat certain information or types of information is or is not present inthe transmitted data, and performs other operations as described ingreater detail below. Generally, each financial institution 205 definesthe specifics and protocols associated with its respective reverse proxy117 and/or DMZ, and thus data transmitted between each OPS 207 and theOMS 211 should comply with these protocols.

As shown in FIG. 2, an advertiser 213 (i.e., Pizza Pub) generates atargeted marketing campaign (TMC) within the OMS 211 via an OMSadvertiser portal 900 (see FIG. 9 and its associated discussion forfurther details regarding the OMS advertiser portal). Before a campaignis created, de-identified consumer transaction data is transmitted fromthe financial institution's transaction processor 220 to the OPS 207,which stores the data for subsequent use. This data is aggregated by theOPS and accessed by the OMS as needed for campaign generation. Thefinancial or consumer transaction data is de-identified of any consumer-or account-identifying information via an internal financial institutionde-identifying process and stored in a de-identified consumertransaction table (see FIG. 17 and its associated discussion). Eachfinancial institution 205 that is connected to and utilizes aspects ofthe TMS 215 employs its own protocol for removing identifyinginformation from consumer financial transactions. Such identifyinginformation is removed to protect consumer privacy, maintain security,etc. Thus, the transactions data received by each OPS includes aplurality of financial transactions indicating merchants involved in thetransactions, merchant types, spend amounts, dates, payment mechanismtypes, and other similar information. However, the information does notinclude specific consumer names, account numbers, or other identifyinginformation.

The de-identified financial transaction data is aggregated in the OPS211, and accessed by the OMS for use in generation of TMCs andassociated TMOs 113. Generally, a TMC is an advertising campaignconstructed by an advertiser 213, advertising agency, or other entitydesigned to generate and place advertisements in the form of TMOs anddisplay such TMOs to consumers 103 via the consumers' online financialinstitution portals. Each TMC typically includes one or more TMOs 113related to the overall theme of the TMC. As an advertiser 213 creates acampaign and groups consumers into targeted consumer segments (TCS's),the aggregated transaction data provides an accurate estimate as to thenumber of consumers each TMO will reach based on the most recentde-identified consumer transaction data available across all OPS' s inthe TMS 215. Thus, the advertiser 213 is able to modify the specifics ofeach TMO based on the size of the projected consumer segment associatedwith each offer (discussed in greater detail below).

Typically, the TMOs presented to consumers 103 within embodiments of thepresent TMS 215 are targeted based on purchases made by each consumerand related information associated with those purchase. When anadvertiser 213 creates an offer, the advertiser typically defines asegment of consumers that will receive the offer based on one or moretransactions completed by the consumers. For example, an advertiser 213may target an offer to consumers who spent a certain amount of money ata particular retailer during a given time period in a defined zip code.Advertisers can identify, based on aggregated consumer transaction data,approximately how many consumers the offer will reach. The advertisers,however, are unaware of any specific consumers that actually receive orredeem the presented offers, as the advertisers are never given anyspecific consumer-identifying information.

Once a campaign, and its associated offers, is finalized by theadvertiser 213, the offers are stored in the OMS 211, transmitted toeach OPS 207 via each corresponding reverse proxy 217 (and/or DMZ), andthen matched with actual consumer transactions or OTEs that satisfy theoffer criteria. The resulting matched offers are stored in thecorresponding OPS for potential delivery to consumers. As each consumer103 logs in to his or her specific account(s) via the respective onlinefinancial institution portal, the matched offers corresponding totransactions or OTEs are injected or merged into the graphical displayof the consumer's financial institution portal, thus transforming theconventional financial institution portal display into one that includesone or more TMOs (described in greater detail below).

In the example overview 200 shown in FIG. 2, a consumer 103 engages in atransaction with a merchant 101 (i.e., advertiser competitor PizzaKing). For ease of reference, this transaction corresponds to theexemplary transaction discussed in association with FIG. 1 and in otherparts of this disclosure. Because this transaction satisfies one or moreoffers generated by an advertiser 213 via the OMS 211 (discussed ingreater detail below), the transaction qualifies as an offer-qualifyingpurchase (OQP) 115. As will be understood and appreciated, thistransaction may have taken place either before or after the offer towhich it will be matched was created. A record of the OQP 115 istransmitted from the merchant 101 to the financial institution(typically, via a payment mechanism processor, such as a credit cardreader), and identified and recorded within the financial institution205 (particularly, within the financial institution transactionprocessor system 220) in a financial institution database along withnumerous other transactions of the respective consumer 103, as well asother consumers and clients of the financial institution. As will beunderstood and appreciated, in order for the financial institution toidentify and record the transaction, the OQP is completed via a paymentmechanism associated with one of the consumer's accounts held at thefinancial institution, such as a credit card, debit card, prepaid card,gift card, paper check, wire transfer, or other similar payment vehicle,and is thus viewable via the consumer's online banking portal.

After the OQP 115 been recorded within the financial institutiondatabase, all consumer-identifying information is removed from the OQP(i.e., it is de-identified), it is then transmitted to the OPS 207 forstorage in an OPS database and potential matching with TMOs 113. As willbe understood by one of ordinary skill in the art, the de-identifiedtransactions may be transmitted to the OPS on a continual basis, orbatch processed and transmitted once daily, or transmitted via someother similar recurring transmission method. According to oneembodiment, upon receiving the de-identified transactions, the OPStransmits all un-identified “raw” merchant names (i.e., those thatcannot be recognized within the OPS's current database) to the OMS 211in order to be “cleansed,” categorized, and validated via a merchantidentification process (see FIG. 5 and its associated discussion). Thosemerchant names that are successfully associated with an existingvalidated merchant are returned to the respective OPS and subsequentlystored within the OPS (e.g., in a validated merchant table, as discussedin association with FIG. 7).

The OPS 207 then performs a matching process between received TMOs andreceived de-identified transactions to match TMOs to transactions thatsatisfy the criteria of the TMOs (see FIG. 15 and its associateddiscussion). After an offer is matched to a particular transaction (or aparticular consumer's account), identifiers associated with both theoffer and transaction (or account) are then stored in a matched offertable (see FIG. 18 and its associated discussion). According to oneaspect, TMOs are matched to OTEs, such as groupings of transactions by aconsumer, and such matches are stored in an OPS database. As will beappreciated, some consumer transactions will not satisfy any TMOs, andthus no offer is matched to or displayed with these transactions in theconsumer's financial institution portal.

Still referring to the exemplary embodiment of the TMS 215 shown in FIG.2 and in accordance with aspects of the present systems and methods,when a consumer 103 logs into his or her financial institution portalafter the OQP 115 has been matched to an offer, the offer 113 isdisplayed to the consumer in perceptible association with the OQP. Inone embodiment, the TMS 215 utilizes a JavaScript document object model(DOM) injection to inject matched offers into the graphical userinterface (GUI) associated with the financial institution portal whenthe interface is displayed to the consumer (discussed in greater detailbelow). Using this method, a relatively minimal amount of software code(typically, only a few lines of JavaScript code) are input into thefinancial institution's online environment (i.e., webpage-renderingsoftware code at web server 219) that operates the financialinstitution's online portal. When executed, this JavaScript code calls aseparate algorithm stored within an OPS 207 that merges the matchedoffers with their corresponding transactions or OTEs in the renderedfinancial institution webpage. Although a preferred embodiment of thepresent system 215 utilizes a DOM injection to perform this mergingprocess, other embodiments are not limited to this particular method,and other similar methods may be used.

It is understood that banks and other financial institutions aretypically wary of modifying their systems to add functionality providedby a third party. This wariness stems from concerns about compromisingthe security of the bank and the effort required to make even minorchanges to these complex systems. Thus, by utilizing a DOM injection atthe point of display of the portal to the consumer 103, only a minimalamount of code is input into the financial institution's internal code,and advertisers 213 and other system operators of the TMS 215 have noaccess to the financial institution's code itself (or its data).Further, based on this minimally invasive insertion of a small amount ofcode into the financial institution's software, aspects of the TMS andfinancial institution system are able to operate independently of eachother. Thus, if a problem occurs within the TMS, then the financialinstitution is able to operate in its conventional manner until theproblem is rectified, and vice versa. Additionally, aspects of the TMS215 may be updated or modified over time without requiring modificationof the financial institution's software, as the TMS code that is writteninto the financial institution's software is merely a call to a largercode base stored within each OPS 207.

Still referring to FIG. 2, after a consumer 103 views a TMO 113associated with the consumer's OQP 115, the consumer may elect to redeemthe TMO according to the TMO specifics. As shown, the consumer 103redeems the TMO 113 with the advertiser via a redemption qualifyingpurchase (RQP) 117. The RQP, in this example, is a payment of $28.93 atan advertiser (i.e., Pizza Pub) location. For ease of reference, thisRQP 117 corresponds to the exemplary RQP shown and discussed previouslyin conjunction with FIG. 1, and in other parts of this disclosure. Arecord of the RQP is transmitted to the financial institution 205 inmuch the same manner as the record of the OQP 115. Again, the financialinstitution records the OQP and transmits it to the OPS 207. In oneembodiment, the OPS 207 then performs a redemption process to determineif the transaction completed by the consumer 103 satisfies any of theredemption criteria of the TMO(s) previously presented to the consumer(i.e., whether the transaction is in fact an OQP) (see FIG. 23 and itsassociated discussion for further details on this process).

If the consumer's transaction qualifies as a RQP 117 as stipulated bythe TMO, then the OPS records the instance of that RQP within itsrespective offer redemption table and simultaneously calculates the typeand amount of reward (i.e., ORP 225) earned by the consumer. In thepresented example, the account to which the consumer's RQP was chargedhad been associated with a “cash back” rewards program (as shownsubsequently in this disclosure), and thus no further conversion isneeded (as the advertiser had entered the reward value of TMO(s) indollars). In the event an ORP requires conversion from cash into anothertype of reward (e.g., airline miles, points, etc.), the conversion isperformed within the OPS based on each financial institution's specificconversion rate(s) for the account associated with the RQP. According toone embodiment, several transactions or a series of transactions must becompleted by a consumer in order to qualify as an RQP (e.g., if an offerdictates three purchases at a particular advertiser must be made in agiven time period). Or, in some embodiments, the reward is paid out overan extended time period (e.g., several months) if a consumer continuesto make a particular type of purchase or stay enrolled in a particularclub or program (e.g., a movie rental membership). In one embodiment,the consumer 103 is notified of the ORP via an icon 119, message, orsome other indicator evidencing that an offer has been successfullyredeemed (see FIG. 27 and its associated discussions for furtherdetails).

According to one aspect of the TMS 215, financial institutions 205 arereimbursed directly by advertisers via the TMS for the value of allrewards paid to consumers 103. For example, advertiser may havepre-funded accounts within the TMS that are used to reimburse financialinstitutions for ORPs 225. Or, in some embodiments, the TMS includes ageneral fund that is used to pay financial institutions, which is inturn compensated by advertisers 213 after the payments to consumers havebeen made. Additionally, in one embodiment, advertisers pay the operatoror operating entity of the TMS for the ability to create and deliverTMCs and subsequent TMOs to consumers (i.e., not just for reimbursementof reward value, but for privilege to use TMS functionality).

As will be understood and appreciated, advertiser creation of campaigns,segments, and offers, consumer redemption of those offers, transmissionof data between the OMS 211, each OPS 207, and each financialinstitution 205, and other processes of embodiments of the TMS 215 shownand described in conjunction with FIG. 2, occur on a continual andongoing basis. Further, over time, offer redemptions and/or impressionsare tracked and recorded by each OPS 207, and this data is transmitted(preferably, in aggregation) to the OMS 211 for reporting to advertisers213. In this way, advertisers are able to determine the relativeeffectiveness of their campaigns, manage their return on investments(ROI), and adjust future campaigns and advertisements based onperformance of previous campaigns and offers.

Additionally, in one embodiment, a system operator or manager has accessto all TMS 215 components, and controls and manages overall TMSoperations. The system manager accesses the system via a managementportal 2915 (see FIG. 29) to perform maintenance on the system, updateor make changes to the system, and complete other management tasks.

Referring now to FIG. 3, the system architecture 300 for one embodimentof the disclosed targeted marketing system (TMS) 215 is shown. As shown,the architecture 300 includes the OMS 211, at least one OPS 207,databases 305, 307, a plurality of firewalls 330, at least one reverseproxy 217 and the Internet 209. Additionally, the overall systemarchitecture 300 includes connections to one or more financialinstitutions 205 (including the institution's internal transactionprocessor(s) 220 and web server(s) 219) and each institution'sassociated database(s) 309. As will be understood, although only one OPS207 and one financial institution 205 are shown in the embodiment ofFIG. 3, other embodiments include a plurality of OPS's 207 and aplurality of financial institutions 205. Further, as will beappreciated, although only one database is shown each for the OMS, OPS,and the financial institution, embodiments of the present TMS 215utilize many databases to store system information as needed. In oneembodiment, more than one OMS 211 is utilized to perform the campaigncreation and management functions of the system. Aspects of the internalhardware components associated with each OMS and OPS are shown anddiscussed in conjunction with FIGS. 29-30.

According to a preferred embodiment, the OMS 211, OPS 207, and financialinstitution 205, and their respective components, communicate with eachother via a conventional service-oriented architecture (SOA). Generally,a service-oriented architecture is an information technologyinfrastructure that allows different applications to exchange data withone another. Typically, a SOA separates functions into distinct units orservices, which are made accessible over a network (such as theInternet), such that users of the system can combine and reuse them asdesired. As will be understood, the communication protocol between thesystem components shown in FIG. 3 may vary depending upon each financialinstitution's preferred communication technique, and other similar filetransfer mechanisms may be used according to embodiments of the presentsystem.

In the embodiment shown in FIG. 3, the internal components (i.e.,processor(s), memory(ies), etc.) of the OMS and OPS are represented byblocks 211 and 207, respectively (see FIGS. 29-30 for more detailedrepresentations). Also included as part of the OMS and OPS are OMSdatabase 305 and OPS database 307, respectively. The OMS database 305stores data and other information used in the generation of targetedmarketing campaigns (TMCs), analysis of campaign performance, and othersimilar OMS processes. In one embodiment, the OMS database 305 includesa campaign table 1100, segment table 1200, and offer table 1300(described in greater detail below) for storing campaign- andadvertising-related data (collectively referred to as “campaign data”315). Preferably, the OMS database also includes a local instance ofcampaign results data 301 (discussed below), such as that shown in acampaign results table 2600. In one embodiment, the OMS database alsoincludes a merchant identification table 600 for storing data andinformation used in the cleansing and categorization of merchant names.

The OPS database 307 stores data and other information used in matchingTMOs to transactions or offer-triggering events (OTEs), displaying suchTMOs to consumers, recording redemptions of TMOs, and other similar OPSprocesses. In one embodiment, the OPS database 307 includes ade-identified consumer transaction table 1700, matched offer table 1800,and campaign results data 301 (represented by the offer impression table2400 and offer redemption table 2500 (described in greater detailbelow)) for storing data relating to matched transactions and offers,redeemed offers, etc. According to one embodiment, the OPS database alsoincludes a validated merchant table 700 which effectively serves as arepository for data required to match “raw” merchant names originatingfrom a payment mechanism processor (e.g., credit card reader) tovalidated (i.e., “normalized”) merchant names suitable for matchingoffers and redemptions (discussed in greater detail below).

Additionally, within the financial institution 205 is at least onefinancial institution database 309 for storing consumer transactioninformation. In one embodiment, the financial institution database 309includes a master consumer transactions table 1600 for storing allconsumer transactions recorded within the financial institution.Additionally, in one embodiment, the financial institution databasestores an instance of de-identified consumer transaction table 1700 (notshown) for subsequent transmission to the OPS. As will be understood andappreciated by one of ordinary skill in the art, consumer transactionsthat have not been de-identified (i.e., those in transactions table1600) remain within the financial institution database, and areunavailable to components of the TMS. As will be further understood,embodiments of the present TMS 215 are not limited to the specifictables mentioned in association with the databases 305, 307, 309, asother tables and data necessary for successful operation of the TMS aswill occur to one of ordinary skill in the art are included as well.

As will be understood and appreciated, the various components of aspectsof the TMS (i.e., the OMS 211 and each OPS 207) and each financialinstitution 205 must share data in order to carry out their respectivefunctions. However, different protocols exist for sharing data dependingon the data type. Importantly, even though it is stripped ofconsumer-identifying information, de-identified consumer transactiondata never leaves the OPS (for purposes of regulatory compliance andconsumer privacy concerns). Thus, when the OMS requires consumertransaction data for campaign generation, the OMS makes a query into theOPS, and the OPS returns an aggregated total of consumers and/ortransactions associated with the particular request. For example, as anadvertiser creates a particular segment, the OMS requests from the OPSthe total number of consumers or transactions that satisfy the segment,and the OPS returns such an aggregated total (and, in one embodiment,the aggregated purchase histories of the consumers at a merchant ormerchant group associated with the segment). However, no specificde-identified transactions ever leave the OPS. For other, less sensitivetypes of data, similar access calls are made between system components.Or, according to another embodiment, although data tables may begenerated and stored within one system component (e.g., campaign data315 is typically generated within the OMS), instances of the data tablesare transmitted to other system components as needed and cached locallyfor subsequent use (i.e., “master” v. “local” tables). Again, however,de-identified consumer transaction data is retained within the OPSbehind the financial institution's security components.

As shown in FIG. 3, communications between the OMS 211 and OPS 207 passthrough one or more firewalls 330, as well as reverse proxy 217.Generally, each firewall is an integrated collection of securitymeasures designed to prevent unauthorized electronic access to itsassociated, networked computer system. Depending on the particularfinancial institution 205, each firewall is a dedicated appliance orsoftware that inspects network traffic passing through it and denies orpermits access to network components based on a set of predefined rules.Often, based on heightened security measures typically associated withfinancial institutions 205, each institution has multiple firewalls, andvarious distributed components within the institution are located behindvarying levels of security (discussed below). In one embodiment, the OMS211 also includes a firewall 330a to inspect data and information passedto and from it over the Internet 209. As will be understood, eachfirewall is configured according to financial institution or systemadministrator protocols.

According to the embodiment shown, both the financial institution 205and the OPS 207 utilize distributed architectures with disparatecomponents residing behind varying firewalls 330 b-c (i.e., securitylevels) for performing functions that require varying levels ofsecurity. As shown, an initial firewall 330 b separates the Internet 209(and, thus, external components, such as the OMS 211) from the financialinstitution web server 219, the OPS application components 207, and thereverse proxy 217. The area including these components is generallyreferred to as a demilitarized zone (DMZ) (also referred to as a“demarcation zone” or “perimeter network”), which is defined elsewhereherein. Some embodiments of the present system utilize a DMZ in additionto or in lieu of a reverse proxy to provide additional or alternatesecurity measures. The financial institution web server 219 and OPSsever 207 that reside in the DMZ generally perform the functions ofserving web page content to consumers 103, injecting offers into theserved web pages, and other similar functions. Behind a second firewall330 c with enhanced security measures reside the financial institutiontransaction processor 220, financial institution database 309, and OPSdatabase 307. Generally, these components are included behind anadditional security layer because they store sensitive consumerinformation and conduct secure processes, such as matching offers toconsumer transaction data, etc. As will be understood, the architectureshown in FIG. 3 is exemplary only, and various financial institutions205 employ varying architectures and security measures depending on theinstitution's preferences.

According to a preferred embodiment, in addition to one or morefirewalls, a reverse proxy 217 is utilized to provide an extra layer ofsecurity to each financial institution's local area network (LAN). Inone embodiment, the reverse proxy 217 comprises computers and/orprocessors acting as proxy servers to intercept and inspect all inboundand outbound communications between components on either side of thereverse proxy (in this case, the OPS 207 (in conjunction with thefinancial institution 205) and the OMS 211). In the embodiment shown,the OPS 207 operates behind both the reverse proxy and the financialinstitution firewall(s), such that the financial institution and the OPShave a direct communication link (ad described above). In this manner,any information or data passing into or out of the OPS (specifically,from the OMS) is subject to the same layers of protection and securityas required by the financial institution.

Because of these security components present between the OPS 207 and theOMS 211 (and Internet 209, etc.), embodiments of the TMS 215 are able tooperate in compliance with financial institution regulatory guidelines.

Offer Management System (OMS)

As described previously, embodiments of the offer management system(OMS) 211 enable advertiser creation of targeted marketing campaigns(TMCs), targeted consumer segments (TCS's), and targeted marketingoffers (TMOs), cleansing, categorization, and validation of unidentifiedmerchant names, reporting of marketing data and campaign results toadvertisers, transmission of data to and from one or more offerplacement systems (OPS's), and other similar processes. Because TMCs arecreated via the OMS and then transmitted to individual OPS's installedat separate financial institutions, advertisers are able to create TMCsthat are presented across a plurality of financial institutions.Further, because each OPS matches the TMCs to consumer transactionswithin each financial institution, advertisers are able to market andadvertise to consumers based on actual consumer purchase behaviorwithout compromising the privacy or security of the consumer'stransaction data. Details and specific functionality associated with theOMS and its processes will now be further described.

FIG. 4 is a flowchart 400 illustrating the overall processes andfunctions performed by the OMS 211 according to one embodiment of thepresent TMS 215. As will be understood and appreciated, the steps of theprocess 400 shown in FIG. 4 are not necessarily completed in the ordershown, and the processes of the OMS operate concurrently andcontinuously. Accordingly, the steps shown in FIG. 4 are generallyasynchronous and independent, computer-implemented, tied to a particularmachine (the OMS 211 of a TMS 215), and not necessarily performed in theorder shown. As shown, one of the OMS processes includes the campaigngeneration process 1000 to generate targeted marketing campaigns,whereby campaigns are created based on advertiser-entered campaignspecifics (described in greater detail below in conjunction with FIGS. 8and 10). During the process 1000, in response to advertiser creation oftargeted consumer segments, the OMS requests segment population totals(i.e., the number of consumers associated with a particularadvertiser-defined segment based on de-identified consumer transactions)from each OPS 207 to assist advertisers in campaign creation (step 401).Once received by the OMS, the population totals are aggregated toprovide a sum of all consumers (and their associated transactions)eligible to receive a TMO associated with a segment or segments to helpadvertisers determine the scope of their campaigns (step 403).

Although the segment population request step 401 and segment populationreceipt step 403 are shown in FIG. 4 as associated with the OMS process400, such steps may also be viewed as being a part of the campaigngeneration process 1000, but are shown and described in FIG. 4 inconnection with the operations of the OMS for ease of understanding andclarity.

Other processes associated with generation of campaigns is described ingreater detail below. After a campaign has been created, the campaigndata 315 (including campaign, segment, and offer information) istransmitted to each OPS 207 via one or more reverse proxies 217 forfurther processing and display to consumers 103 (step 405).

After a TMC's completion (or during its operation), an advertiser maydesire to view and analyze results of the campaign (e.g., number ofconsumers that have viewed offers associated with the TMC, number ofoffers redeemed, specific competitor locations of redeemed offers,etc.). Thus, in response to an advertiser query, the OMS requestscampaign results data from each OPS (step 407). Upon receiving therequest, embodiments of each OPS 207 will collect and transmitaggregated campaign results data 301 to the OMS 211 for advertiserreview (step 409). In one embodiment, the campaign results data isdisplayed to advertisers via an OMS advertiser portal 900 in the form ofstatistics, graphs, charts, percentages, or other similar conventionalreporting formats (discussed in greater detail below).

Also included in the overall OMS processes 400 is the merchantidentification process 500, in which unidentified merchant names areanalyzed and identified (if possible) for subsequent use (described ingreater detail below in conjunction with FIG. 5). Based on local cardprocessing systems, naming conventions, and other factors, merchantnames associated with consumer transactions are often sent frommerchants to a given financial institution (and subsequently to anassociated OPS) in several different formats, even though eachrepresents (and is associated with) the same merchant. For example,prior to being “cleansed” within the OMS 211, hypothetical merchant 101Pizza King may be represented as “PK #29483”, “Pizza K”, “P. King Inc”,and/or numerous other variations within the transaction data received bythe financial institution 205 (and eventually sent to its OPS(' s) 207).Accordingly, in order for the present system to recognize namevariations as corresponding to a single merchant entity for purposes ofmatching consumer transactions to offers, initiating payment ofredemptions based on RQPs, and other processes as described herein, eachname should preferably be identified and categorized according to anexisting, validated merchant name.

FIG. 5 is a flowchart of an embodiment of a computer-implementedmerchant identification process 500 carried out by a particular machine(e.g. OMS 211) for identifying and “cleansing” (i.e., normalizing)unidentified merchant names received from an OPS 207. As mentioned,because merchant names in transaction data may comprise a variety offormats, even though the names all represent or are associated with asingle merchant 101, the names should be identified and linked to thatmerchant for a variety of purposes (described above). For many merchantnames associated with consumer transactions, an OPS is able to clearlyidentify the merchant associated with a given name (e.g., because theparticular name format corresponds to a previously-identified name fromprevious transactions), and thus the name is never transferred to theOMS for identification. For others, however, the merchant name must beidentified before further transaction processing, matching, etc., canoccur.

Starting at step 501, a request for unidentified merchant names istransmitted from the OMS 211 to one or more OPS's 207. At step 503, theOMS verifies whether any unidentified merchant data was received from anOPS. If unidentified merchant data was received, then such data isstored within the OMS database 305 or in an OMS local memory, and apredetermined merchant identification algorithm is performed utilizingthe received data to identify corresponding merchant names (describedbelow) (step 505). If no merchant data (i.e., names) is received, thenthe OMS again requests data from the OPS (step 501). As will beunderstood, steps 501 and 503 are performed on a looping basis tocontinually request or check for incoming merchant name data. Inalternative embodiments, the OMS requests data from the OPS periodically(e.g., hourly, daily, etc.), or at the specific request of a systemoperator, or via some other protocol as will occur to one of ordinaryskill in the art. In a further embodiment, rather than a request forunidentified merchant names being transmitted from the OMS to an OPS,the OPS automatically transmits unidentified merchant names to the OMSas discovered within transaction data.

Once the requested unidentified merchant names are received, apredetermined merchant identification algorithm interprets data fields(i.e., cleanses or “scrubs” the data) within the names in order toeffectively identify the merchant associated with each merchant name(step 505). According to one embodiment, the predetermined algorithmfirst removes all non-alphabetic data from the unidentified merchantname before then comparing the result against a stored list ofpreviously-validated merchant names. According to various embodiments,the stored list comprises predefined names entered by a system operatoras corresponding to particular merchants, names that were previouslyvalidated via the merchant identification process 500, common variantsor patterns in name formats recognized across all unidentified merchantnames, and/or other names as will occur to one having ordinary skill inthe art. Based on the comparison to the stored list, each unidentifiedmerchant name is assigned an identity assurance score or rating relativeto a valid merchant name to which it is most likely associated.Generally, the identity assurance rating comprises a percentage-basedmeasure of the likelihood that a given unidentified merchant name isassociated with an existing valid merchant name. As will be understood,the identity assurance rating for a given unidentified merchant name canbe calculated according to a number of factors, such as the percentageof alphabetic characters that match a name on the stored list of names,or based on particular word matches or ordering of characters, etc.After an identity assurance score is calculated for each unidentifiedmerchant name, each name is stored in a merchant identification table600 for further processing (discussed in greater detail below inconjunction with FIGS. 6 and 7).

Once an unidentified merchant name receives an identity assurance score,the name is classified as either “validated” (i.e., identified orrecognized) or “un-validated” based on the assurance score. According toone embodiment, a system operator defines a threshold assurance score(e.g., 80%, 90%, 100%, etc.) that must be met in order to classify amerchant name as “validated.” At step 507, the process 500 determineswhether a given merchant name was identified (i.e., validated) or not.Generally, unidentified merchant names receiving an identity assurancescore above the predefined threshold are deemed to have an associationwith an existing valid merchant name, and thus require no furtheridentification efforts (i.e., they are deemed “validated”). If anunidentified merchant name receives an identity assurance score belowthe predefined threshold, an optional manual identification process istypically initiated (step 509). In some embodiments, however, ratherthan manually identifying merchant names, the unidentified names aresimply discarded, and the transactions associated with those names aremade unavailable for offer matching and other functions.

Still referring to FIG. 5, one embodiment of the manual identificationprocess comprises manual review by a system operator of eachunidentified merchant name, whereby the operator makes a “best guess” toeither classify the name according to a known (i.e., validated) merchantname, or label it as “un-validated.” In another embodiment, the manualidentification process comprises an electronic search according to apredetermined algorithm of existing and readily available resources(e.g., online databases or Internet search) in an attempt to effectivelyidentify the merchant name. If, through the manual identificationprocess, an unidentified merchant name is successfully identified, themerchant name is given “validated” status. If a name cannot beidentified via the manual process, then the name is discarded, and thetransactions associated with the name are made unavailable for matchingand other functions.

Upon completion of both the predetermined and manual identificationprocesses (steps 505 and 509), the now validated merchant names arestored within a validated merchant table 700 in the OMS database (step511) (discussed in greater detail below in conjunction with FIG. 7).According to one embodiment, only validated merchant names stored withinthe validated merchant table 700 are transmitted to each OPS forsubsequent processing (step 513).

FIG. 6 is an exemplary merchant identification table 600 illustratingdata associated with unidentified merchant names utilized or generatedduring the merchant identification process 500. FIG. 7 is an exemplaryvalidated merchant table 700 illustrating data associated with validatedmerchant names. In the embodiment shown, tables 600 and 700 includeidentical data categories or fields, except that table 700 includes onlymerchant names that were officially validated via the merchantidentification process 500 (e.g., because their identity assurance scoreexceeded a predetermined threshold). As will be understood by one havingordinary skill in the art, tables 600, 700 are presented forillustrative purposes only, and embodiments of the present system 215are not limited to use of the specific data tables shown.

As shown, the tables 600, 700 each include six data categories orfields: unidentified merchant key 601, unidentified merchant name 603,validated merchant key 605, validated merchant name 607, merchantcategory 609, and identity assurance rating 611. As will be understood,however, the data categories or fields are not limited to the fieldsshown, and other embodiments include additional fields as will occur toone of ordinary skill in the art. As will also be understood, althoughonly five data entries are shown in table 600 (i.e., entriescorresponding to unidentified merchant keys 349, 103, 184, etc.), andthree data fields are shown in table 700 (i.e., entries corresponding tounidentified merchant keys 349, 785, 293), actual data tablesconstructed in accordance with aspects of the present system may includea virtually unlimited number of entries corresponding to a plurality ofmerchant names processed by embodiments of the present TMS 215.

As shown, the unidentified merchant key field 601 indicates a uniqueidentifier generated by an embodiment of the TMS 215 and assigned toeach unidentified merchant name received from an OPS (i.e., previouslyextracted from consumer transaction data). Although the unidentifiedmerchant keys are illustrated as 3-digit numbers, it will be appreciatedthat these unique identifiers may comprise many formats, includingnumber strings of longer length, hexadecimal identifiers, binaryidentifiers, and the like. The unidentified merchant name field 603indicates the specific merchant name extracted from a given consumertransaction. The validated merchant key field 605 indicates anidentifier that corresponds to a validated merchant name (shown in field607) to which the unidentified merchant name is likely associated (basedon the identification process 500). For example, exemplary unidentifiedmerchant keys 103 and 184 correspond to unidentified merchant names“SKATE ESCP” and “S ESCAPE HOUSTON”, respectively. Based on the merchantidentification process, the system has determined that both of theseentries likely represent merchant “SKATE ESCAPE”, which has validatedmerchant key 23. Similarly to the unidentified merchant keys, thevalidated merchant keys may comprise many formats, and are not limitedto the specific 2-digit format shown.

Still referring to FIGS. 6 and 7, the merchant category field 609indicates the category or categories assigned to each validated merchantname. As described herein, merchant category information is usedprimarily for purposes of defining targeted consumer segments, althoughother uses are possible. According to one embodiment, each validatedmerchant name is associated with only one merchant category. Inalternate embodiments, however, merchants are associated with aplurality of categories as apply to their particular businesses.Generally, merchants are categorized according to conventional industrycodes as defined by a selected external source (e.g., a merchantcategory code (MCC), Hoovers™, the North American IndustryClassification System (NAICS), etc.). However, in one embodiment,merchant categories are assigned based on system operator preferences,or some other similar categorization process.

The identity assurance rating field 611 indicates the identity assurancescore calculated for each unidentified merchant name (as describedpreviously in conjunction with FIG. 5). As shown, the entriescorresponding to unidentified merchant keys 103 and 184 are not includedin table 700, indicating that their respective identity assuranceratings (90% and 70% , respectively) were below the predefined thresholdfor the shown embodiment. Thus, the transactions associated with thoseunidentified merchant names will be unavailable for subsequent OPSprocesses. Representative merchant name entry 613 corresponds to thePizza Pub/Pizza King example referenced in other parts of thisdisclosure.

Referring now to FIG. 8, a flowchart is shown illustrating a campaigngeneration process 800 from the perspective of an advertiser 213according to an embodiment of the present targeted marketing system 215.Such steps are generally computer-implemented, and tied to theoperations of a particular machine (OMS 211), but are herein describedfrom the perspective of the advertiser to enable a person skilled in theart of computer programming to construct a suitable computer-implementeduser interface. Generally, a campaign comprises one or more targetedmarketing offers which can be delivered to one or more targeted consumersegments. In one embodiment, however, rather than creating anoverarching campaign, an advertiser simply creates a singular offer fordelivery to consumers (discussed in greater detail below). Additionally,the process 800 shown in FIG. 8 merely represents one path to creatingand/or editing campaigns, segments, and offers, and other paths arepossible within embodiments of the present system (e.g., defining offerspecifics before or simultaneously with campaign specifics).

As shown in FIG. 8, at step 801, an advertiser 213 logs into the OMSadvertiser portal 900 to begin creation of a campaign. FIG. 9illustrates an exemplary OMS advertiser portal 900 that is displayed toan advertiser during the operations of the campaign generation process800 in accordance with aspects of the claimed invention(s). As will beunderstood and appreciated, the person that physically creates thecampaign may be an employee of the advertiser (e.g., a member of themarketing team), or a member of an advertisement agency, or some otherthird party with authorization to create campaigns on behalf of theadvertiser. At step 803, the advertiser 213 decides whether he or she iscreating a new campaign, or accessing and editing a preexisting(prestored) campaign. If it is a new campaign, the advertiser definesthe campaign specifics (e.g., the name of the campaign, the start andend date of the campaign, etc.) (step 807). If, however, the advertiseris accessing a preexisting (prestored) campaign, then the advertiserselects the particular campaign from a list of the advertiser's storedcampaigns via the OMS advertiser portal 900 (step 805). Once selected,the advertiser 213 either confirms the preexisting campaign specifics,or edits the specifics and saves (stores) the changes to the campaign(step 807). Exemplary campaign data is illustrated in table 1100 shownin FIG. 11.

After a campaign has been created or accessed, the advertiser 213decides whether he or she wishes to create a new consumer segment, oraccess a preexisting (prestored) segment associated with the campaign(step 809). Generally, a segment defines a particular group of consumers103 that will receive offers based on the transactions completed by theconsumers. Regardless of whether an advertiser 213 creates a newsegment, or accesses a preexisting segment from a list of storedsegments (step 811), the advertiser defines the segment by a dimension(again, via the OMS advertiser portal 900) (step 813). If it is apreexisting segment, the advertiser may simply confirm the dimension ordimensions associated with the segment.

As defined previously herein, a “dimension” refers to a delineatingcategory that serves to narrow the population of consumers that mayreceive an offer associated with the segment based on criteriaassociated with specific consumer transactions. Examples of dimensionsinclude the location of the transaction (e.g., zip code(s), city(ies),etc.), the merchant (e.g., Pizza King) or merchant type (e.g.,restaurants) with which the transaction was completed, the amount spent,the specific category of items purchased, the payment mechanismassociated with the transaction, etc. According to one embodiment,segments (and their associated dimensions) are used to identify andtarget consumers based not on specific consumer transactions, but onpatterns and trends associated with transactions over time (e.g.,consumers with high volumes of transactions at health food stores).After the advertiser has defined the segment by at least one dimension,the advertiser is queried as to whether he or she wishes to furtherdefine the segment (step 815). If so, steps 813 and 815 are repeateduntil the segment has been completely defined to the advertiser'ssatisfaction. If not, the segment is saved (stored), and the advertiser213 moves forward in the campaign generation process 800. Exemplarysegment data is illustrated in table 1200 shown in FIG. 12.

Still referring to FIG. 8, once at least one segment has been defined oraccessed by an advertiser 213, the advertiser either creates a new offerassociated with the segment, or accesses a preexisting (prestored) offerfrom a list of stored offers (step 817) and assigns it to a respectivesegment. Typically, a TMO 113 defines an offer for a reward if theconsumer 103 completes some subsequent, redemption-qualifying purchase(RQP) 117 or series of purchases with the advertiser 213. For example,an offer may dictate that the consumer will receive $10 off any purchaseover $25 made at an advertiser location in the month of June. Often, theoffer may include an advertiser logo or advertising statement, such as“Pizza Pub voted country's best breadsticks!”. In one embodiment,however, rather than an offer in which consumers are offered a rewardfor completing a RQP 117, the offer is purely an advertisement for theadvertiser 213 (i.e., the “offer” does not necessarily have to includean associated consumer reward). For example, the offer may simplycomprise the statement: “Pizza Pub voted country's best breadsticks!”,with no corresponding reward offer. As will be understood andappreciated, a plurality of offer specifics (i.e., offer defininginformation) may be defined by advertisers 213 according to embodimentsof the present TMS 215.

Regardless of the offer specifics, these specifics are defined at step821. If a preexisting offer was selected (step 819), the advertiser 213either confirms or edits preexisting specifics, or defines newspecifics. After at least one offer specific has been defined, theadvertiser is queried as to whether he or she wishes to further definethe offer 113 (step 823). If so, steps 821 and 823 are repeated untilthe offer has been completely defined to the advertiser's satisfaction.If not, the offer is saved (stored), and the advertiser moves forward inthe campaign creation process 800. Exemplary offer data is illustratedin table 1300 shown in FIG. 13.

At step 825, the advertiser 213 decides whether he or she wishes to“publish” the campaign. If not, the campaign creation process 800 isended, and the generated campaign is stored for subsequent use. If,however, the advertiser does choose to publish the campaign, then thepublish process is initiated 827. Generally, the publication process isinitiated once the advertiser is completely satisfied with the campaignand its associated offer(s), and is ready to deliver the offers toconsumers 103. In one embodiment, the publish process comprisestransmitting the finalized campaign, segment, and offer data to each OPS207, wherein the data is analyzed and verified by each financialinstitution 205 and/or a system operator according to each institution'sprotocols. Essentially, the offers are screened to ensure that theycomply with the financial institution's specifications (e.g., theformatting is compliant, they do not contain explicit or offendingmaterial, etc.), as well as advertising regulations and practices. Oncethe financial institution is satisfied with the content and format ofthe campaign, the associated offers are matched to qualifyingtransactions and delivered to consumers (described in greater detailbelow). According to one aspect, an advertiser 213 may elect to createand store several offers associated with a campaign, and then publishthe campaign (and its associated offers) all at once. In another aspect,offers are published individually.

Another aspect of embodiments of the campaign generation process 800 isthe “dynamic resegmentation” process (not shown). As used herein,“dynamic resegmentation” refers to the process of automaticallydelivering follow-up TMOs to consumers that redeem original or initialTMOs. In one embodiment, during the campaign generation process 800,after offers have been defined, advertisers have the option to define afollow-up offer that is automatically presented to a consumer thatredeems an initial offer. The typical goal, from the advertiser'sperspective, is to entice the consumer to purchase the advertiser'sgoods and/or services more than once in the hopes of obtaining theconsumer as a repeat and loyal customer.

As mentioned previously, in one embodiment, campaigns, segments, andoffers are created within the OMS 211 via an OMS advertiser portal 900.FIG. 9 illustrates an exemplary screen shot of a graphical userinterface (GUI) associated with an embodiment of the OMS advertiserportal 900. Through this portal, advertisers 213 perform the functionsof campaign, segment, and offer creation, campaign management, campaignreporting and analysis, billing, and other similar OMS processes. Aswill be understood and appreciated, the GUI shown in FIG. 9 is presentedfor illustrative purposes only, and other formats and displays of GUIsare used in other embodiments of the present TMS 215.

The portal display 900 shown in FIG. 9 is a representative display forand on behalf of hypothetical advertiser, Pizza Pub, a user of the TMS215. As shown, the portal display includes a “Campaign Menu” section ordisplay region 903, a “My Campaigns” section 905, a “Manage Segments”section 907, a “Manage Offers” section 921, and an estimated populationdisplay section 901. As will be understood and appreciated, othersections and fields in addition to those specifically listed and shownin FIG. 9 are possible according to other embodiments of the presentsystem.

As shown, the “Campaign Menu” section 903 is a conventional GUI menuthat enables management of TMCs and basic campaign-related functions,such as creating new TMCs, editing existing TMCs, saving and discardingTMCs, and retrieving help or support information. The “My Campaigns”section 905 illustrates folders including the advertiser's storedcampaigns from each month. As will be understood, campaigns may belisted according to date, merchant or competitor name, merchant oradvertiser category, etc., and are not limited to display according tothe month or months to which the campaigns pertain (as shown in FIG. 9).In the embodiment shown, the “My Campaigns” section 905 comprises aconventional hierarchical display, wherein a representative campaign(i.e., “Pizza King”) is shown as selected. As will be appreciated, TMCsare named according to each advertiser's preferences, typically based onthe overall theme of the campaign. For example, the illustrativecampaign is targeted to customers of advertiser competitor 101 PizzaKing, and thus the campaign has been named “Pizza King”. Because thisparticular campaign has been selected from the advertiser's library ofcampaigns, the TCS's and TMOs illustrated in the “Manage Segments” and“Manage Offers” sections 907, 921, respectively, coincide with theselected “Pizza King” campaign.

Although not shown, each campaign generally includes a start date andend date. In one embodiment, campaign delimiting information such as acampaign name, start date, end date, etc., are defined via conventionaldata entry fields within the OMS advertiser portal (not shown). Thestart and end date associated with a campaign typically defines when acampaign runs (i.e., when transactions are monitored to determinesatisfaction of segment and offer specifics, discussed below), but othersignificance may be assigned to the start and end dates, as will occurto one having ordinary skill in the art.

In the embodiment shown, the “Manage Segments” section 907 is theinterface in the portal display 900 through which TCS's are createdand/or edited. As will be understood, the representative dimensions 911,913, 915 are presented merely for illustrative purposes, and embodimentsof the TMS 215 are not limited to the specific dimensions shown. In“Segment Name” field 909, an advertiser defines a name for a newsegment, or accesses the system to retrieve a previously-created segmentfrom a drop down menu associated with field 909. For example, the nameof the selected segment shown in FIG. 9 is “Pizza King (Calif.)”, likelyindicating a segment targeted to consumers of Pizza King stores inCalif. In the “Location(s)” field 911, the advertiser defines thelocation of consumers (and specifically, consumer transactions) to whichTMOs will be targeted. In one embodiment, the “Location(s)” field 911defines the physical location in which consumer transactions occurred.In another embodiment, however, the “Location(s)” field defines thelocation of the billing address associated with a consumer account heldat a financial institution 205. As will be understood, the “Location(s)”dimension, as well as all other dimensions, may be defined according toadvertiser and/or system operator preferences. Additionally, in variousembodiments, locations are represented by zip or postal codes, cities,states, and other similar geographical indicia.

Still referring to FIG. 9, in the “Merchant(s)” field 913, theadvertiser identifies the merchant or advertiser competitor(s) 101 withwhich transactions or purchases were (or will be) completed. In oneembodiment, specific merchants are identified via a pre-populated listin the “Merchant(s)” field 913. In other embodiments, however, generalbusiness categories are defined (e.g., retail, home repair,entertainment, sporting goods stores, etc.). In the “Spend Amount” field915, a minimum amount is defined that a consumer 103 must have spent inorder to qualify for and receive a TMO associated with the definedsegment. According to one embodiment, the spend amount applies only to asingle consumer transaction. In another embodiment, however, the spendamount is an aggregated total of a particular consumer's transactionsover a given time period that satisfy the other, defined dimensionsassociated with the segment.

As mentioned, the specific dimensions shown (911, 913, 915) arepresented for illustrative purposes only, and other similar dimensions,such as specific items purchased, overall number of transactionscompleted by each consumer, average number of transactions completed byeach consumer in a given time period, payment mechanism used, types ofmerchants (e.g., luxury, discount, health and beauty, etc.) eithershopped or not shopped during a given time period, etc., are utilizedaccording to various embodiments of the present TMS 215. Additionally,according to one aspect, segments are defined that include as few as onedimension. For example, an advertiser 213 may elect to deliver TMOs toall consumers 103 that engage in transactions with a particular merchant101, regardless of the location of the transaction, the spend amount,etc. Further, some segments may be directed to the advertiser's currentcustomers (as opposed to consumers of competitors) in order to reinforceconsumer loyalty.

Still referring to the “Manage Segments” section 907, the time periodfields 912 define time periods in which the respective dimensions areapplied. According to various embodiments, the time period may beabsolute (e.g., purchases made in August 2008) or relative to a presentdate of the campaign (and its associated segments and offers). Forexample, if an advertiser is working to create a campaign on June 1 in agiven year, and the time period 912 for a particular dimension dictatestransactions in the last 30 days, then any consumers performingtransactions occurring within 30 days prior to June 1 (i.e., May 2-May31) are subject to the respective dimension, and thus will be reflectedin the “Est. Segment Population” field 919 (discussed below). As will beunderstood, the time periods 912 may indicate any time period defined byan advertiser or system operator as will occur to one of ordinary skillin the art.

According to one embodiment, the time period fields 912 dictate timeperiods in which consumer transactions are monitored or aggregated toanalyze consumer spending habits. For example, an advertiser 213 maywish to create an offer-triggering event (OTE) associated with a segmentof consumers that complete more than 5 transactions with a givenmerchant 101 over a predefined time period. Or, an advertiser may definea segment of consumers to receive offers that had a total spend amountabove a predetermined threshold over a given time period. Accordingly,the advertiser is able to associate OTEs with segments of consumersbased not on individual transactions, but on patterns of transactionsover time.

As dimensions are defined by an advertiser 213 for a given segment, the“Est. Segment Population” field 919 displays an estimated total numberof consumers 103 that will receive offers associated with the givensegment. Generally, the “Est. Segment Population” field 919 refreshes todisplay an updated number of potential consumers each time a newdimension is defined by the advertiser, or each time a time period field912 is adjusted. Accordingly, the advertiser is able to narrow orenlarge the scope of the consumer segment by adding, narrowing, orremoving dimension specifics in order to achieve a desired number ofconsumers to receive offers. According to one embodiment, each time asegment dimension is defined, or a time period field adjusted, the OMS211 queries each OPS 207 for aggregated consumer transactioninformation, and the OPS returns an aggregated population of consumersthat satisfy the segment (based on the consumers' de-identifiedtransactions stored in each OPS database 307). In the exemplary portaldisplay 900 shown in FIG. 9, approximately 3,245 consumers are estimatedto be eligible to receive an offer associated with the given segmentbased on the dimensions as defined.

As mentioned, the estimated number of consumers shown in field 919 isdetermined based on the aggregated de-identified consumer transactiondata received/accessed from each OPS 207. If the advertiser 213 feelsthat the estimated number of consumers 103 is too high, but theadvertiser does not want to vary the segment dimensions, a “TargetRatio” can be defined in “target ratio” field 917. For example, anadvertiser is able to elect to deliver offers to a random percentage ofconsumers within a given segment (e.g., only 30% of consumers in asegment will receive a TMO). Additionally, according to one embodiment,the system is preconfigured to reject or block segments that carve outan exceedingly narrow scope of consumers. For example, if an estimatedconsumer population associated with a given segment falls below 300consumers, then the system indicates to the advertiser that it mustbroaden the segment in order to proceed. The purpose of a preconfiguredminimum segment population is to enhance consumer privacy and preventsegments from becoming too narrow (i.e., enabling an advertiser toidentify actual consumers based on overly specific segments). As will beunderstood, the preconfigured minimum segment population may be set atany number that a system operator desires.

As segments are defined, estimated population display field 901 providesa graphical display of consumers in a given segment. As shown, customeruniverse icon 937 represents the entire population of consumersavailable for targeting as a function of the particular financialinstitution(s) 205 connected to the TMS 215. In one embodiment, thistotal number of consumers is displayed when the advertiser 213 interactswith the icon 937 by hovering a cursor over the icon (i.e., “mouseover”), or clicking on the icon, etc. Segment display field 939identifies the currently selected segment (i.e., “Pizza King (Calif.)”),and lists the estimated number of consumers in the segment (whichcorresponds to the “Est. Segment Population” field 919). Segment displayfield 941 identifies the number of consumers in the available consumerpopulation that are not subject to the selected segment. In the exampleshown in FIG. 9, field 941 indicates that an estimated 58,349,204consumers will not be eligible to receive a TMO because they have not(or likely will not) engage in transactions that satisfy the selectedsegment dimension criteria.

As will be understood, in various embodiments of the present system,multiple segments may be created and/or edited simultaneously. In theseinstances, display field 901 displays icons and segment information foreach selected segment. Further, according to some embodiments, thenumber of consumers 103 indicated in display field 901 is merely anestimate of the total number of consumers that will receive offersassociated with a selected segment. In these embodiments, an estimatednumber is provided (as opposed to an actual number), because, dependingon the particular campaign or segment, the campaign may apply only tofuture transactions, and so a specific, accurate total cannot bedetermined. Again, as mentioned, only aggregated consumer transactiondata is transmitted to the OMS, so no consumer-identifying informationor specific account numbers are ever transmitted, and thus advertisersremain unaware of specific consumers that receive (or may receive) TMOs.

Still referring to FIG. 9, in the embodiment shown, the “Manage Offers”section 921 is the interface in the portal display 900 through whichTMOs are created and/or edited. As will be understood, therepresentative offer specifics (e.g., “Reward Amount”, “Image”, etc.)are presented merely for illustrative purposes, and embodiments of theTMS 215 are not limited to the particular specifics shown. In the “OfferName” field 923, an advertiser 213 defines a name for a new offer, orretrieves a previously-created offer from a drop down menu associatedwith field 923. For example, the name of the selected offer is “PizzaKing (June)”, likely indicating an offer that is (or will be) targetedto consumers of Pizza King stores in June of the selected year.

As shown, “Start date” and “End date” fields 925, 927 define the startand end dates between which TMOs 113 will be presented to consumers 103.In one embodiment, the start and end dates defined in fields 925 and 927map directly to the campaign start and end dates. In other embodiments,however, the offer start and end dates are independent of the campaignstart and end dates, and define the time period in which offers will bedisplayed to (i.e., viewable by) consumers via their financialinstitution portals. In one embodiment, both campaign and offer startand end dates correspond to monthly time periods (i.e., the first andlast days of a month) to coincide with traditional financial institutionbilling cycles. As will be understood, time periods for campaigns,segments, and offers are defined to correspond to varying criteria asdesired by a system operator or advertiser.

Still referring to the “Manage Offers” section 921, in the “RewardAmount” field 929 (i.e., incentive or offer amount), the advertiser 213defines an amount or value for the selected TMO. Generally, this amountis a value the consumer 103 will receive off of his or her purchase oras a credit to his or her financial institution account if he or she“redeems” the offer (i.e., engages in a RQP 117). In general, the amountdefined in the “Reward Amount” field 929 is entered by the advertiser asa dollar value or percentage of purchase and, if necessary, converted toeach consumer's appropriate rewards type as determined by the rewardstype associated with each consumer's account. In one embodiment, thisconversion process is carried out within each OPS before requesting anoffer redemption payment be issued to the consumer by the financialinstitution (described in greater detail below in conjunction with FIG.23). In another embodiment, the reward amount value is converted torewards currency before the offer is ever displayed to the consumer. Inthe “Image” and “Text” fields 931, 933, respectively, advertisers havethe capability to include an image (such as an advertiser logo) or textin the TMO.

As will be understood, the offer defining information shown (925, 927,929, 931, 933) is presented for illustrative purposes only, and othersimilar specifics, such as redemption methods, minimum RQP 117 spendamounts for redemptions to apply, particular advertiser locations atwhich redemption occurs, etc., are utilized according to variousembodiments of the present TMS 215. Additionally, according to oneembodiment, offers do not necessarily require (or make available)redemption. Some offers, for example, are simply advertisementsindicating an advertiser logo or text. Once an advertiser 213 issatisfied with the segment and offer as defined, the advertiser mayelect to save the segment and offer via Save button 935. Once saved, thesegment and offer are stored in the OMS database 305 in their respectivecampaign file. Further, if the advertiser wishes to publish the campaign(or in other embodiments, individual offers), then the advertiserselects Publish Campaign button 943. Once published, the campaign (andits associated segments and offers) are subject to the publish process,described previously in conjunction with FIG. 8.

Also shown in the exemplary OMS advertiser portal 900 are Billing andReporting tabs 945, 947, respectively. When an advertiser 213 selectsBilling tab 945, a billing screen is displayed (not shown), in which theadvertiser is able to make deposits into a TMS account to cover consumerredemptions and/or manage payments directly to an identified systemoperator (or third party payment entity), track payouts to consumers,and perform other billing functions. When an advertiser selectsReporting tab 947, a reporting screen is displayed (not shown), in whichthe advertiser is able to review statistics and analytics associatedwith the advertiser's campaign(s). Such performance data is recorded byeach OPS 207 and transmitted to the OMS 211 for advertiser review.Generally, the OMS provides informative displays (such as charts,graphs, tables, etc.) and other data indicating the performance (i.e.,success) of the advertiser's campaign(s), both historically and invirtually real-time. Such information includes total number of offersredeemed, total number of offer impressions (i.e., views of an offer byconsumers), total amount spent at advertiser locations in conjunctionwith offer redemption, amounts spent at advertiser locations as comparedto competitor locations, and other similar reporting information.

As will be understood and appreciated by one of ordinary skill in theart, the fields and sections shown in the exemplary OMS advertiserportal 900 shown in FIG. 9 generally comprise conventional data entryfields, such as drop down menus, free-form text entry fields, selectablebuttons, etc.

Referring now to FIG. 10, a flowchart is shown illustrating oneembodiment of a computer-implemented campaign generation process 1000from the perspective of the operational steps carried out by the TMS215. The process 1000 illustrated in FIG. 10 coincides closely with thecampaign generation process 800 shown in FIG. 8, except that FIG. 8tracks the campaign generation process from the advertiser perspective,whereas FIG. 10 describes computer-implemented steps of the campaigngeneration process from the system perspective (in response toadvertiser-entered data). At step 1001, the system 215 displays a GUIassociated with the OMS advertiser portal 900 to an advertiser 213.Generally, the advertiser either selects a preexisting campaign orchooses to generate a new campaign. Accordingly, the system receives theadvertiser's selection (step 1003). If a new campaign is selected (step1005), the system awaits and subsequently receives campaign data enteredby the advertiser (step 1009). If a preexisting campaign is selected(i.e., a campaign previously created by the advertiser), the systemaccesses the preexisting campaign (step 1007), and then receivesadvertiser-entered campaign data (if any). Once all campaign-relateddata has been received, the data is stored in the OMS database 305 (step1011) (see FIG. 11 for exemplary campaign table that reflects andrepresents stores campaign-related data).

After a campaign has been selected and stored, an associated segment istypically created or selected for editing. If a new segment is selectedfor creation (step 1013), the system awaits and subsequently receivessegment data entered by the advertiser (step 1017). If a preexistingsegment is selected (i.e., a segment previously created by theadvertiser), the system accesses the preexisting segment (step 1015),and then receives advertiser-entered segment data (if any). Once allsegment data has been received, the data is stored in the OMS database305 (step 1019) (see FIG. 12 for exemplary segment data table).

After a segment has been selected and stored, an associated offer istypically created or selected for editing. If a new offer is selectedfor creation (step 1021), the system awaits and subsequently receivesoffer data entered by the advertiser (step 1025). If a preexisting offeris selected (i.e., an offer previously created by the advertiser), thesystem accesses the preexisting offer (step 1023), and then receivesadvertiser-entered offer data (if any). Once all offer data has beenreceived, the data is stored in the OMS database 305 (step 1027) (seeFIG. 13 for exemplary offer data table). At step 1029, the systemqueries the advertiser 213 as to whether the advertiser would like topublish the campaign. If the advertiser does not wish to publish thecampaign, then the campaign generation process 1000 is ended. If,however, the advertiser does wish to publish the campaign, then thecampaign data is transmitted to each OPS 207 and the publication processis initiated (discussed previously).

FIGS. 11, 12, and 13 are exemplary data tables or structuresillustrating representative data that was received and stored during thecampaign generation process 1000. As mentioned previously, thecollection of data contained in these tables (i.e., tables 1100, 1200,1300) is generally referred to herein as “campaign data” 315. As will beunderstood, tables 1100, 1200, 1300 are presented for illustrativepurposes only, and embodiments of the present system 215 are not limitedto use of the specific data tables shown. In one embodiment, the threedisparate tables are merged into one large data file within the OMSdatabase 305. In another embodiment, a relational data table or index(not shown) stores and associates each campaign ID with itscorresponding segment ID(s) and offer ID(s) such that offers, segments,and campaigns may be queried and tracked in relation to one another.

FIG. 11 is an exemplary campaign table 1100 illustratingadvertiser-entered, campaign-related data received during campaigngeneration, as reflected by a plurality of entries in the table, eachentry having a plurality of predetermined data fields. As shown, thetable 1100 includes five data categories or fields: campaign identifier(ID) 1101, advertiser identifier (ID) 1103, author identifier (ID) 1105,campaign start date 1107, and campaign end date 1109. As will beunderstood, however, the data categories or files are not limited to thefields shown, and other embodiments include additional fields, includingthose mentioned previously herein, as well as those not mentioned thatwill occur to one of ordinary skill in the art. As will also beunderstood, although only five data entries are shown in the table(i.e., entries corresponding to exemplary and illustrative campaign IDs10000-10004), actual data tables constructed in accordance withembodiments of the present system may include a virtually unlimitednumber of entries corresponding to a plurality of campaigns created byadvertisers 213 utilizing aspects of the present system.

As shown, the campaign ID field 1101 indicates a unique campaignidentifier associated with each campaign. Each campaign identifier isgenerated by an embodiment of the TMS 215 and associated with arespective campaign as each campaign is generated by an advertiser 213.Although the campaign IDs are illustrated as 5-digit numbers, it will beappreciated that these unique identifiers may comprise many formats,including number strings of longer length, hexadecimal identifiers,binary identifiers, and the like. The advertiser ID field 1103 indicatesthe particular advertiser associated with each campaign. The author IDfield 1105 indicates the individual system user that actually createdeach campaign. Further, the campaign start and end date fields 1107,1109 indicate the beginning and end dates for each campaign. Asmentioned previously and according to various embodiments, these datesmay or may not correspond to offer start and end dates, may or may notcoincide with financial institution account billing cycles, etc.Representative campaign 1111 corresponds to the Pizza Pub/Pizza Kingexample referenced in other parts of this disclosure.

FIG. 12 is an exemplary segment table 1200 illustratingadvertiser-entered, segment-related data received during campaigngeneration, as reflected by a plurality of entries in the table, eachentry having a plurality of predetermined data fields. As shown, thetable 1200 includes five data categories or fields: campaign identifier(ID) 1101, segment identifier (ID) 1201, location 1203, merchantcategory/merchant 1205, and spend amount 1207. In particular, it will beappreciated that the campaign ID 1101 provides a link or connection of aparticular segment to a particular campaign, so that a particularsegment represented by an entry in a segment table is associated with aparticular campaign. For example, in the entry 1209, the segment ID55555 is a segment associated with campaign ID 10000.

It should be understood that the data categories or files are notlimited to the fields shown in FIG. 12, and other embodiments includeadditional fields, including those mentioned previously herein, as wellas those not mentioned that will occur to one of ordinary skill in theart. As will also be understood, although only five data entries areshown in the table (i.e., entries corresponding to segment IDs55555-55559), actual data tables constructed in accordance withembodiments of the present system may include a virtually unlimitednumber of entries corresponding to a plurality of segments created byadvertisers 213 utilizing aspects of the present system.

As shown, the segment ID field 1201 indicates a unique segmentidentifier associated with each segment. Each segment identifier isgenerated by an embodiment of the TMS 215 and associated with arespective segment as each segment is generated by an advertiser 213.Just as with the campaign identifiers, the segment identifiers comprisevarious formats within various embodiments of the present TMS 215, andare not limited by the 5-digit number format shown. Additionally, aseach segment identifier is generated, it is associated with a respectivecampaign identifier (shown in campaign ID field 1101 in the segmenttable 1200) within the OMS database 305 to create a link between thesegment and its corresponding campaign. The link between the segmentsand campaigns enables information in both tables to be accessed wheneither a specific segment or campaign is queried or accessed. Thelocation field 1203 indicates, in one embodiment, one or more locationsin which consumer transactions that are part of each respective segmentmay occur. In another embodiment, the location field 1203 indicates thelocation of consumer billing addresses. In further embodiments, thelocation field 1203 represents another location as will occur to one ofordinary skill in the art.

Still referring to FIG. 12, merchant category/merchant field 1205indicates a particular merchant 101 (FIG. 1), merchants, or category ofmerchant with which consumer transactions that are part of therespective segment are carried out. Generally, the spend amount field1207 indicates a minimum amount that each consumer must have spent,either via a single transaction or cumulatively across many transactionsover the specified campaign time period, in order to qualify as part ofa given segment. As shown, representative segment 1209 corresponds tothe Pizza Pub/Pizza King example referenced in other parts of thisdisclosure.

FIG. 13 is an exemplary offer table 1300 illustratingadvertiser-entered, offer-related data received during campaigngeneration, as reflected by a plurality of entries in the table, eachentry having a plurality of predetermined data fields. As shown, thetable 1300 includes eight data categories or fields: campaign identifier(ID) 1101, segment identifier (ID) 1201, offer identifier (ID) 1301,offer amount 1303, offer start date 1305, offer end date 1307, offertext 1309, and offer image 1311. As will be understood, however, thedata categories or fields are not limited to the fields shown, and otherembodiments include additional fields, including those mentionedpreviously herein, as well as those not mentioned that will occur to oneof ordinary skill in the art. As will also be understood, although onlyfive data entries are shown in the table (i.e., entries corresponding tooffer IDs 99999-99995), actual data tables constructed in accordancewith embodiments of the present system may include a virtually unlimitednumber of entries corresponding to a plurality of offers created byadvertisers 213 utilizing aspects of the present system.

As shown, the offer ID field 1301 indicates a unique offer identifierassociated with each offer. Each offer identifier is generated by anembodiment of the TMS 215 and associated with a respective offer as eachoffer is generated by an advertiser 213. Just as with the campaign andsegment identifiers, the offer identifiers comprise various formatswithin various embodiments of the present TMS 215, and are not limitedby the 5-digit number format shown. Additionally, as each offeridentifier is generated, it is associated with a respective segmentidentifier and campaign identifier (shown in campaign ID field 1101 andsegment ID field 1201 in the offer table 1300) within the OMS database305 to create a link between the offer and its corresponding segment andcampaign. The link between the offers, segments, and campaigns enablesinformation in any of tables 1100, 1200, or 1300 to be accessed when aspecific offer, segment, or campaign is queried or accessed.

Generally, the offer amount field 1303 indicates a reward amount orvalue a consumer 103 will receive if he or she completes a RQP 117associated with the offer. The offer amount is generally entered by anadvertiser within the OMS advertiser portal 900 as either a dollaramount or a percentage of a subsequent RQP, although otheradvertiser-entered offer amounts are possible within embodiments of thepresent system as will occur to one of ordinary skill in the art. In oneembodiment, the offer amount is converted to an equivalent value offinancial institution rewards currency (e.g., points, miles, etc.)before the offer is displayed and/or paid to the consumer (described ingreater detail below in conjunction with FIG. 23). Typically, if theoffer amount is converted to rewards currency, it is so converted byeach OPS 207 based on predetermined conversion ratios set by eachfinancial institution 205. In one embodiment, each consumer accountassociated with a particular rewards currency at a financial institutionis grouped into a portfolio for that particular rewards currency toenable efficient conversion of offer amounts. In an alternateembodiment, the offer amount is predefined by an advertiser in a rewardscurrency or currencies, and thus offers are only displayed to consumersthat have accounts that utilize the specific defined rewardscurrency(ies). As mentioned, according to the preferred embodiment, theoffer amount is automatically issued/paid to each consumer's account bythe respective OPS 207 and financial institution 205 once (if) a RQP hasoccurred.

Although not shown, in one embodiment of the present system 215, anoffer-qualifying amount is defined as an item of offer defininginformation, indicating a minimum amount a consumer 103 must spend viathe RQP 117 in order to receive the reward (i.e., offer amount). Forexample, an advertiser may dictate that, after a consumer has receivedan offer, the consumer must spend more than $25 in a follow-up purchaseor purchases in order for the purchase(s) to qualify as an RQP. In theoffer start and end date fields 1305, 1307, beginning and end dates areindicated for offer presentment to consumers. According to oneembodiment, advertisers 213 may elect to “abandon” an offer (or entirecampaign) prior to the end date if, for example, the consumer responserate to the campaign or offer was higher than expected. Generally,however, if an offer or campaign is abandoned, consumers that havealready received the abandoned offer will remain eligible to redeem itaccording to its stipulated offer specifics.

Still referring to FIG. 13, the offer text field 1309 indicates amessage, advertisement, or text presented to each consumer 103 with eachrespective TMO. Further, the offer image field 1311 indicates an imageor picture uploaded and defined by an advertiser 213 to be included withthe offer. Generally, the image comprises a advertiser logo, butvirtually any image may be included. As shown, representative offer 1313corresponds to the Pizza Pub/Pizza King example referenced in otherparts of this disclosure.

Offer Placement System (OPS)

As described previously, embodiments of the offer placement system (OPS)207 enable matching of received campaign data from the offer managementsystem (OMS) 211 with de-identified consumer transaction data receivedfrom financial institutions 205, injecting or merging targeted marketingoffers (TMOs) into financial institution portals for review by consumers103, transmission of unidentified merchant names to the OMS forvalidation, organizing and transmitting offer redemption data tofinancial institutions for reimbursements to consumers, transmitting ofresults (i.e., performance) data to the OMS, and other similar processesas described herein. Generally, at least one OPS 207 is in operativeassociation with each financial institution location, preferably locatedbehind the institution's firewall(s) and reverse proxy 217, thusenabling direct communication with each financial institution whilemaintaining financial institution-level security with outside components(such as the OMS) (see FIG. 3 and its associated discussion for furtherdetails of OPS and financial institution architecture). Details andspecific functionality associated with the OPS and its processes willnow be further described.

FIG. 14 is a flowchart illustrating the overall computer-implementedprocesses and functions performed by the OPS 207 according to oneembodiment of the present TMS 215. As will be understood andappreciated, the steps shown in FIG. 14 are not necessarily completed inthe order shown, as the OPS operates on a continual and recurring basis,and the steps shown in FIG. 14 are associated with disparate functionsof the OPS. Accordingly, the steps shown in FIG. 14 are generallyasynchronous and independent, computer-implemented, tied to a particularmachine (OPS 207), and not necessarily performed in the order shown. Asshown, starting at step 1401, the OPS 207 monitors for incomingde-identified consumer transaction data from the financial institution205. If data is received, then such data is stored within the OPSdatabase 307 in a de-identified consumer transaction table 1700(described in greater detail below) for further processing (steps 1403,1405). If no data is received, then the OPS again monitors for receiptof data (step 1401). As will be understood, steps 1401 and 1403 areperformed on a looping basis to continually check for incoming consumertransaction data. In one embodiment, data is transmitted from thefinancial institution periodically (e.g., hourly, daily, etc.), and thusthe OPS only monitors for incoming data once per period.

Once received, the consumer transaction data is stored in the OPSdatabase 307 (step 1405). The stored data comprises an instance orsubset of the representative data shown in de-identified consumertransaction table 1700, which comprises de-identified transactionscompleted by various consumers. The consumer transaction data isutilized for matching consumer transactions to campaigns and offers(discussed in greater detail below in conjunction with FIG. 15). Uponreceiving and storing the de-identified transaction data, the OPSdetermines whether any of the merchant names in the data areunidentifiable, and then extracts and transmits all unidentified namesto the OMS to be identified and categorized via the merchantidentification process 500 (described previously) (step 1407). Afterexecuting the merchant identification process, the OMS returns allvalidated merchant names to the OPS (step 1409), which then stores thereceived, validated merchant names within a validated merchant table 700in the OPS database 307 for subsequent use in matching transactions tooffer data.

As described previously, during campaign generation, the OMS 211transmits requests to the OPS 207 for aggregated consumer transactiondata that satisfies various segments created by advertisers. Thus, atstep 1413, the OPS receives such a request for segment populationtotals. Upon receiving such request, the OPS determines whichde-identified consumer transactions satisfy the segment request,aggregates the determined transaction data, and transmits the data tothe OMS for use in campaign creation (step 1415). According to oneembodiment, a predetermined searching algorithm is used to determinewhich transactions satisfy the segment dimensions associated with therequest (similarly to the matching algorithm used in the matchingprocess 1500, described below in association with FIG. 15).

At step 1417, the OPS 207 monitors for incoming campaign data 315 fromthe OMS 211. If data is received, then the OPS activates the matchingprocess 1500 (described below), whereby the received campaign data isutilized in conjunction with de-identified consumer transaction data formatching consumer transactions to specific offers (steps 1419 and 1500).If no campaign data is received, then the OPS again monitors for receiptof data (step 1417). Generally, the campaign data includes campaign,segment, and offer data such as that shown in FIGS. 11-13. As will beunderstood, steps 1417 and 1419 are performed on a recurring basis tocontinually check for incoming campaign data or updates topreviously-received data. If updated data is received, thenpreviously-matched offers are modified accordingly. In one embodiment,data is transmitted from the OMS periodically (e.g., hourly, daily,etc.), and thus the OPS only monitors for incoming data once per period.As mentioned previously, incoming data may be transmitted in the form ofinstances of local data tables or structures, or may comprise accesscalls to master data stores in other TMS components. As also mentionedpreviously, any incoming data to an OPS from the OMS passes throughfinancial institution firewall(s) 330 and a reverse proxy 217. Thus, alldata must comply with each financial institution's guidelines andprotocols. If it does not, the communication is blocked and an errormessage is transmitted to the respective advertiser and/or OMS operator.

Still referring to FIG. 14, once de-identified consumer transaction dataand campaign data has been received by the OPS, a matching process 1500is initiated to identify which consumers will receive specific TMOs 113based on specific consumer transactions (i.e., offer-qualifyingpurchases (OQPs) 115 or offer-triggering events). The details associatedwith the matching process are described in conjunction with FIG. 15.After offers and transactions have been matched, the matched offers arestored in a matched offer table (see FIG. 18 and associated discussion)in the OPS database 307 where they await injection into financialinstitution consumer portals (or are sent to a consumer via anothermechanism, such as via mobile devices, email, SMS or MMS messages,etc.). As a consumer 103 logs into his or her financial institutionportal to view his or her account(s), an injection process 1900 isperformed, in which the matched offers are merged into the respectivefinancial institution portal for display in association with respectiveconsumer transactions (see FIG. 19 and associated discussion fordetails). Over time, as consumers 103 view the TMOs 113 and redeem themvia RQPs 117, the redemption process 2300 tracks and records viewed andredeemed offers, and instructs financial institutions 205 to issue offerredemption payments (ORPs) 225 to consumer accounts (see FIG. 23 andassociated discussion). As data associated with viewed and redeemedoffers, etc., is collected and stored, the OPS 207 aggregates andtransmits such campaign results data 301 to the OMS 211 in response to arequest from the OMS for such data for processing and display toadvertisers 213.

Referring now to FIG. 15, a flowchart is shown illustrating oneembodiment of a computer-implemented matching process 1500 for matchingTMOs 113 to consumer OQPs 115 or OTEs within an OPS 207. As will beunderstood, the matching process 1500 generally occurs at pre-determinedtime intervals which can be adjusted as new campaign and transactiondata is received within an OPS. At step 1501, stored de-identifiedconsumer transaction data for each consumer is retrieved from thede-identified consumer transaction table 1700 (based on account GUIDs)within the OPS database 307. At step 1503, campaign data 315 is receivedfrom the OMS. As will be understood, steps 1501 and 1503 may occursimultaneously, or in reverse order than that shown. Generally, the datais newly-received data that has not yet been matched (i.e., transactionshave not yet been matched to offers). However, in one embodiment, evenpreviously-matched transactions and offers are re-processed periodicallyto determine if a more appropriate or specific match exists, based on aranking algorithm (discussed below).

Once the de-identified transactions data has been retrieved and thecampaign data has been received, a predetermined matching process isperformed on the data to determine which TMOs each specific consumershould receive (step 1505). Preferably, the matching algorithm utilizesa conventional, hierarchical matching process that compares segment data(such as that shown in FIG. 12) to de-identified consumer transactiondata (such as that shown in FIG. 17) to determine which transactionssatisfy which segments (i.e., the system compares each transaction in alist of transactions to elements of campaign data). For example, anamount 1611 of a given transaction or purchase may be compared to thespend amount 1207 for each available segment. If the transactionsatisfies the spend amount for one or more segments, then the nextdimension of the identified segment(s) are processed, and so on. As willbe appreciated, if a given transaction fails to satisfy any segments,then no offer is matched to the transaction.

Once the OPS 207 confirms that a specific consumer's transaction(s)match the dimensions for a respective segment, then the TMO associatedwith the segment is retrieved (based on related offer and segment IDs)and stored as an identified match with the transaction(s) for subsequentprocessing and display to consumers (as explained below in conjunctionwith FIG. 19). According to one embodiment, each TMO specifies where itshould be placed (i.e., displayed) in a consumer's financial institutionportal. For example, offers may be placed underneath a transaction,adjacent to a transaction, in a side bar, in a pop-up advertisement,etc., within the financial institution portal. Further, when an offer isplaced underneath a transaction, the advertiser can define, via the OMSadvertiser portal 900, whether the offer is placed beneath a transactionfrom a specific merchant, beneath a transaction from merchants oradvertisers of similar type to the advertiser, or beneath anytransaction. Based on predetermined rules defined by a financialinstitution or system operator, the OPS determines precisely where todisplay the offer when it is presented to a consumer.

It will be appreciated by one having ordinary skill in the art that,under some circumstances, more than one offer will apply to a giventransaction. In these circumstances, and according to one embodiment,once all offers have been matched to a transaction, a predeterminedranking algorithm is utilized to determine which offer will be displayedwith the particular transaction. In one embodiment, the rankingalgorithm is customized to a system operator's or financialinstitution's specifications. For example, in one embodiment,advertisers 213 pay additional fees to the TMS operator to give theiroffers higher priority. In other embodiments, offers are ranked based onthe overall perceived value of the offer (e.g., offer amount 1303), andthe offer with the highest value to the consumer is selected as thematched offer.

Other variables for ranking are considered in other embodiments, such asthe consumer's predicted responsiveness to each offer (e.g., based onthe number of the consumer's transactions in a given merchant category),whether other offers from the particular advertiser have been previouslypresented to the particular consumer (determined based on the accountGUID, discussed below), etc. According to still further embodiments,rather than ranking potential offers, if a given transaction satisfiesmore than one segment, all matched offers associated with the satisfiedsegments are subsequently displayed to the consumer.

After each OQP 115 or OTE is matched to a respective TMO 113, the match(i.e., the identifiers associated with matched offer and transaction(s))is stored in a matched offer table 1800 (discussed below) until thematched offer is called for display to its respective consumer 103 (step1507). Generally, each OPS database 307 and the data tables storedtherein are formatted to correspond to data structures of theirrespective financial institutions 205. Because of variations in themanner in which financial institutions process and record data, somelevel of customization is generally required when an OPS is formattedfor a given financial institution. However, once installed andformatted, the OPS, financial institution, and OMS integrate seamlesslyto transmit data and perform their respective functions.

FIG. 16 is an exemplary consumer transaction table 1600 illustratingconsumer transactions recorded by a financial institution 205 and storedwithin a financial institution database 309. As will be understood,table 1600 is presented for illustrative purposes only, and embodimentsof the present system 215 are not limited to use of the specific datatable shown. As mentioned previously, the data included in consumertransaction table 1600 is stored at all times within the financialinstitution, and is de-identified before being sent to the OPS(described below). The consumer transaction table 1600 comprisesconsumer transaction data, as reflected by a plurality of entries in thetable, each entry corresponding to an individual transaction, and eachentry having a plurality of predetermined data fields.

As shown, the table 1600 includes seven data categories or fields:account number 1601, account global unique identifier (GUID) 1603,transaction identifier (ID) 1605, zip identifier (ID) 1607, merchantname (or identifier (ID)) 1609, amount 1611, and rewards type 1613. Aswill be understood, however, the data categories or fields are notlimited to the fields shown, and other embodiments include additionalfields as will occur to one of ordinary skill in the art. As will alsobe understood, although only five data entries are shown in the table(i.e., entries corresponding to account numbers 2930928402, 1029478293,etc.), actual data tables constructed in accordance with embodiments ofthe present system may include a virtually unlimited number of entriescorresponding to a plurality of consumer transactions recorded byembodiments of the financial institutions 205.

As shown, the account number field 1601 indicates the specific accountnumber associated with a consumer's account. The account GUID field 1603indicates a unique global account identifier (i.e., a secure identifier)associated with each consumer's account. Prior to transmitting data tothe OPS 207, each financial institution replaces actual consumer namesand/or account numbers with GUIDs, which are a conventional type ofidentifier used when dealing with secure or sensitive data. Generally,each financial institution 205 incorporates its own internal process toconvert actual accounts to GUIDs. Although the account GUIDs areillustrated as 5-digit numbers, it will be appreciated that these uniqueidentifiers may comprise many formats, including number strings oflonger length, hexadecimal identifiers, binary identifiers, and thelike. Conventional GUIDs comprise 32 hexadecimal digits as will be knownto those skilled in the art, such as, for example:3F2504E0-4F89-11D3-9A0C-0305E82C3301.

As will be understood, use of GUIDs in place of actual consumer accountsor consumer identifiers prevents unauthorized access to confidentialconsumer information by components outside of the financial institution205 (e.g., OMS, Internet, etc.). If, however, some sensitive data wereaccidentally transmitted to an OPS 207, no further breach of this datawould occur, as the OPS is in operative association with the financialinstitution behind the financial institution's firewall(s) 330 andreverse proxy 217. Further, the distributed architecture of thefinancial institution and each OPS (as shown previously in FIG. 3)creates additional layers of security for each component.

Accordingly, all private and sensitive consumer information is retainedwithin the financial institution's security mechanisms, thus allowingplacement of TMOs without disclosure of sensitive and confidentialconsumer data.

Still referring to FIG. 16, transaction ID field 1605 indicates a uniquetransaction identifier associated with each transaction. Generally,these transaction IDs are generated and associated by financialinstitutions 205 with transactions in much the same manner as accountGUIDs. In one embodiment, the transaction IDs are represented by add-oncharacters to the account GUIDs, as typically more than one transactionis associated with each account.

In one embodiment, the zip ID field 1607 indicates the zip code (i.e.,location) in which the specific transaction occurred. In otherembodiments, the zip ID field 1607 indicates the zip code of the billingaddress of the consumer associated with the specific account, or someother informational location. As will be understood, the zip ID field isessentially a location identifier, and thus other location indicia maybe included (e.g., city, state, etc.).

As shown, the merchant name field 1609 indicates the specific businessentity with which the transaction occurred. As will be understood, thebusiness entity shown in field 1609 may be a merchant, advertiser,advertiser competitor, etc. The amount field 1611 indicates the amountof the transaction. Further, the rewards type field 1613 indicates theparticular rewards type (if any) tied to the respective account. Foraccounts with only one rewards type, the financial institution indicateswhich type of rewards program is associated with the account in whichthe transaction occurred. For accounts with multiple rewards programs,either a single program is selected by the financial institution, ormultiple programs are indicated in association with the giventransaction in rewards type field 1613. Further, in some embodiments,rather than indicating a rewards type in a consumer transaction table,the rewards type(s) associated with each account is stored in a separatefile (e.g., portfolio of accounts associated with a given rewards type)in the financial institution database 309. Again, transaction data asreferred to herein is not limited by the specific fields shown in FIG.16, and other data items are contemplated, such as merchant categories,amount spent in an overall merchant category, transaction type, specificgoods and/or services purchased, and other similar data fields.Additionally, as shown, representative transaction 1615 corresponds tothe Pizza Pub/Pizza King example referenced in other parts of thisdisclosure.

FIG. 17 is an exemplary de-identified consumer transaction table 1700illustrating de-identified consumer transactions data recorded by afinancial institution 205 and transmitted to its respective OPS 207. Thede-identified consumer transaction table 1700 comprises de-identifiedconsumer transaction data, as reflected by a plurality of entries in thetable, each entry corresponding to an individual transaction, and eachentry having a plurality of predetermined data fields.

As explained and defined previously herein, de-identified transactionsare those in which consumer- and/or account-identifying information hasbeen removed (and typically replaced with a GUID). As will beunderstood, table 1700 is presented for illustrative purposes only, andembodiments of the present system 215 are not limited to use of thespecific data table shown. As shown, table 1700 is identical to consumertransaction table 1600, except that the actual account number associatedwith each transaction has been removed. Accordingly, table 1700 includessix data categories or fields: account global unique identifier (GUID)1603, transaction identifier (ID) 1605, zip identifier (ID) 1607,merchant name (or identifier (ID)) 1609, amount 1611, and rewards type1613. As will be understood, however, the data categories or files arenot limited to the fields shown, and other embodiments includeadditional fields as will occur to one of ordinary skill in the art. Aswill also be understood, although only five data entries are shown inthe table (i.e., entries corresponding to GUIDs 12932, 23049, etc.),actual data tables constructed in accordance with embodiments of thepresent system may include a virtually unlimited number of entriescorresponding to a plurality of consumer transactions recorded byembodiments of the present TMS 215.

FIG. 18 is an exemplary matched offer table 1800 illustratingidentifiers associated with matched transactions (OQPs 115), offers(TMOs 113), and accounts as a result of the matching process 1500. Thematched offer table 1800 comprises matched offer data, as reflected by aplurality of entries in the table, each entry corresponding to thematching of an individual transaction with a specific offer applicableto that transaction, and each entry having a plurality of predetermineddata fields.

As will be understood, table 1800 is presented for illustrative purposesonly, and embodiments of the present system 215 are not limited to useof the specific data table shown. As shown, the table 1800 includes fourdata categories or fields: transaction identifier (ID) 1605, offeridentifier (ID) 1303, account global unique identifier (ID) 1603, andrank 1801. As will be understood, however, the data categories or fieldsare not limited to the fields shown, and other embodiments includeadditional fields as will occur to one of ordinary skill in the art,including offer-triggering event (OTE) identifier (ID), etc. As willalso be understood, although only five data entries are shown in thetable (i.e., entries corresponding to transaction IDs 55550, 37953,etc.), actual data tables constructed in accordance with embodiments ofthe present system may include a virtually unlimited number of entriescorresponding to a plurality of matched consumer transactions andoffers.

As shown, the transaction ID field 1605, offer ID field 1303, andaccount GUID field 1603 correspond to the similarly-identified fieldsshown and discussed previously in conjunction with FIGS. 13, 16, and 17.In one embodiment, when offers and transactions are matched, therespective data entries are pulled or replicated from the respectivedata tables or files and stored in matched offer table 1800. Foroffer-triggering events (OTEs) in which offers are not necessarilymatched to a single transaction, the account GUID field 1603 indicatesto which consumer account a matched OTE corresponds. Rank field 1801identifies the ranking of the particular matched offer as compared toother matched offers for the given transaction or OTE (as mentionedpreviously). Additionally, as shown, representative transaction 1803corresponds to the Pizza Pub/Pizza King example referenced in otherparts of this disclosure.

As will be described below, when a consumer logs into his or herfinancial institution portal and views his or her transactions, theassociated offer(s) are retrieved from matched offer table 1800 (or anequivalent data store) for display to the consumer based on theconsumer's matched transactions or OTEs. As will be understood, however,simply because a transaction has been matched with an offer or OTE doesnot necessarily mean the consumer 103 will actually receive the offer.For example, if a given consumer infrequently views his or her onlinebanking portal, then he or she may never receive a particular offer oroffers. Or, if an offer or OTE has been assigned a low rank, then thatoffer may not be displayed to the given consumer because other,higher-ranked offers apply to the given transaction or OTE. For thisreason (and others), offer views (i.e., “impressions”), in addition tooffer redemptions, are recorded by each OPS 207 for purposes ofreporting to advertisers 213, etc.

Targeted Marketing Offer Injection or Merging into Display of OnlinePortal

FIG. 19, consisting of FIG. 19A and 19B, illustrates acomputer-implemented process for injecting or merging a selectedtargeted marketing offer (TMO) into the display of an online portalprovided by a financial institution, in accordance with aspects of theclaimed invention(s). As will by now be understood, once the disclosedtargeted marketing system (TMS) 215, via the operations of the OMS 211and OPS 207 as described herein, has carried out prior processes ofprocessing transaction data to provide a basis for identifying marketsegments, creating a campaign from such processed transaction data bydetermining appropriate market segments for receiving offers,establishing the terms and conditions for a targeted marketing offerwithin such segments, and determining that predetermined TMO displayconditions have been satisfied by a consumer's action (e.g., apredetermined transaction or other offer-triggering event), the TMS 215displays information corresponding to the TMO to the consumer via theonline portal. In one particular aspect, the TMO information isdisplayed in close juxtaposition, proximity, or other discernibleassociation with the consumer's prior transaction information as theconsumer views the same via their online banking portal.

FIG. 19A is a flowchart illustrating an embodiment of an injectionprocess 1900 for injecting or merging matched offers into an onlinefinancial institution portal in association with consumer transactiondisplays when a consumer logs in and views his or her financialinstitution portal. FIG. 19A is a more generalized offer injectionprocess 1900, whereas FIG. 19B (discussed in greater detail below)illustrates a specific implementation of one embodiment of a documentobject model (DOM) injection process 1900a for injecting offers intoconsumer financial institution portals. In general, embodiments of theclaimed invention(s) utilize a form of “cross-site scripting” in orderto effect the merger or injection of TMOs into the financial institutionportal, or other similar technique which does not require significantcomputing resources, programming, or modification of the financialinstitution web server code that generates the portal on behalf of aconsumer. As known to those skilled in the art, many modern web browserprograms that run on consumers' computers or other web-accessing devices(such as smart phones) include embedded program code execution engines.Such modern browsers include well known programs such as Microsoft'sInternet Explorer, Mozilla Firefox, Apple Safari, Google Chrome, andothers. Embedded program code execution engines include those identifiedas Javascript, Flash, XML, PHP, CSS (Cascading Style Sheets), ASP, andothers.

Generally speaking, such embedded program code is computer-executableprogram code that is downloaded at run time from a web site and executedwithin the browser environment at a local (client) computer, instead ofcode that is executed at a server computer that provides the HTML orsimilar code commonly associated with a “web page.” Further generallyspeaking, a cross-site scripting method typically involves thedownloading of computer program code from a primary web server thatgenerates the display of a web site (such as HTML that generates thefinancial institution portal), which embeds a minimal script or call todownload and run computer program code from another server (e.g. ascript server or another process in the primary web server) that effectsthe functionality of the TMO injection or merger into the portaldisplay.

According to one aspect of the claimed invention(s), and according toone embodiment, a cross-site scripting method utilizes the Javascriptcode execution capability of modern web browsers to run a script thatmerges or injects information corresponding to a targeted marketingoffer into the financial institution portal display of a consumer'saccount history comprising a plurality of transactions of the viewingconsumer. The web page comprising the portal display, typically anaccount history page comprising a list of the consumer's priortransactions, is dynamically adjusted to incorporate (merge, inject) theTMO information into the display of transactions of the financialinstitution portal, in an unobtrusive and aesthetically acceptablemanner and format. Advantageously, the financial institution portal isindependent of and systemically uncoupled from the TMO injection, suchthat (a) the TMO information is seamlessly and unobtrusively presentedto the consumer in accordance with predetermined advertisement placementinformation (such as display the TMO adjacent to a selected transaction,display the TMO in a predetermined position on the portal displayscreen, etc.) and (b) any issues with operation or security of theinjection process will not affect the operation of the financialinstitution portal, which will continue to operate and serve theconsumer's needs whether or not any TMOs are presented.

Although the disclosed embodiments and aspects are described inconnection with use of Javascript code embedded into the HTML of thefinancial institution portal, it should be understood that othertechniques for merging or injecting the TMO information into the portalcan be employed, such as by certain forms of redirection to anothersite, use of browser frames, and the like, but other techniques maypresent technical or business issues that are more complex than a simplemerger or injection operation. For example, the known security policy of“same origin” for a script and a document or code that contains a scriptis satisfied in disclosed aspects of the claimed inventions by use of aproxy at the financial institution web server that redirects a call forscript to the OPS residing within the financial institution's firewallwithin its DMZ.

Prior to discussing the specific methodology of TMO merger or injectionby use of a scripting technique, a more generalized discussion of thepreferred merger or injection process will be provided by reference toFIG. 19A.

Starting at step 1901 in FIG. 19A, an OPS 207 monitors for a call fromits respective financial institution's web server 219 forpreviously-matched offers. In accordance with one aspect of thedisclosed system, each time a consumer 103 logs in to his or herfinancial institution web portal, a call is automatically transmittedfrom the financial institution web server to the OPS to retrieve thematched offers (if any) associated with the particular consumer'saccount transactions (based on the consumer's GUID). In accordance withone disclosed aspect of the claimed invention(s), for this call tooccur, a relatively minimal amount of JavaScript code (or some othersimilar programming language) is inserted into the financialinstitution's banking portal code at a previous time when an OPS isinitially connected to the financial institution 205. When a consumer'sbrowser loads the financial institution portal display (and especiallyan account history page comprising a list of prior transactions of theconsumer), this JavaScript code (i.e., “script call code”) calls alarger segment of code contained within the OPS that performs thefunctions of retrieving matched offers and injecting those offers intothe financial institution's web portal display to the consumer.

The preferred process of utilizing a small amount of software codeinserted into a previously-existing code base to call a disparate andmore extensive algorithm enables connection of the TMS (andspecifically, the OPS) to the financial institution with minimal initialor on-going effort on the part of the financial institution. Preferably,a JavaScript DOM injection is used to access and execute code storedwithin the OPS to modify the financial institution's online portal eachtime a consumer logs in and views his or her account display.Accordingly, there is no server involvement from the financialinstitution's 205 perspective with the TMO injection, as all processesoccur within the OPS 207, except at the point of web display to theconsumer. This functionality is made possible based on the systemarchitecture 300 of embodiments of the TMS 215, wherein each OPS isdirectly connected to each financial institution within the financialinstitution's security infrastructure.

Further, because minimal intrusion into the financial institution'spreexisting software code is required, both the financial institution205 and any associated OPS 207 are free to update and revise their codebases as needed without changing or updating the interaction betweenthese two systems. Additionally, based on the discrete nature of thesystem architecture 300, if problems occur with either the TMS orfinancial institution systems individually, these problems can beconfined within each respective component or domain without affecting orinfecting the other components. As will be known to those of ordinaryskill in the art, while a JavaScript DOM injection is utilized accordingto one embodiment, other embodiments utilize other scripting, cross-sitescripting, or other similar mechanisms for retrieving and renderingupdated financial institution web displays with matched offers.

Still referring to FIG. 19A, if a call is received from the financialinstitution 205 (indicating a consumer 103 has logged in to thefinancial institution portal to view his or her account andtransactions, e.g. via an account history page), then the stored,matched offers associated with the particular consumer's transactionsare retrieved from the matched offer table 1800 maintained by the OPS inthe OPS database 307 (step 1905). If a call is not received, then theOPS 207 again monitors for a call from the financial institution onlinesystem (step 1901) via a continuous monitoring loop. In one embodiment,if a call is received, then the OPS searches its matched offer tableaccording to the GUID associated with the received call from thefinancial institution (step 1905). Once the TMOs (if any) associatedwith a given consumer's transactions are retrieved, informationcorresponding to the selected TMO's is transmitted to the consumer'sbrowser, and the injection process updates the previously rendered webpage associated with the financial institution portal with suchretrieved TMO information, thereby displaying the retrieved offer(s) tothe consumer (steps 1907, 1909) (see FIG. 21). Stated in other words,and according to one aspect of the claimed invention(s), the consumerviews his or her account history page initially as originally intendedand as originally programmed by the financial institution web portal,and that account history page is updated by the consumer's browser,which receives the TMO information asynchronously to the account historyweb page display, by locally executing the injection script whichdynamically and independently modifies the prior account history displayto provide an updated account history display that incorporates the TMOinformation merged therein.

In one embodiment, the updated consumer financial institution web pageis displayed via a hypertext markup language (HTML) web service, orother similar service. As will be understood and appreciated, accordingto one embodiment, calls to retrieve matched offers may occur withrelatively high frequency (possibly hundreds or thousands per minute),and thus the process 1900 shown in FIG. 19A (and particularly steps1901and 1903) is repeated on a continual and rapidly-recurring basis.

Each time the updated financial institution web page is rendered anddisplayed to a consumer 103 (steps 1907, 1909), the OPS 207 records theoffer impression for each displayed offer in the offer impression table2400 (see FIG. 24 and its associated discussion) (step 1911) in the OPSdatabase 307. As defined previously herein, an “offer impression”represents an instance of a consumer logging in to his or her financialinstitution portal 2100 and viewing the displayed offers associated withdisplayed transactions. It is inferred that when an offer is injectedinto the consumer's financial institution portal, the consumer sees theoffer. According to one embodiment, a consumer transaction cannotqualify as a RQP for a particular TMO until the OPS recognizes that atleast one offer impression of the TMO has occurred for the consumer.Furthermore, offer impressions assist advertisers 213 in tracking andassessing the performance of their campaigns and associatedadvertisements, as analytics are determined regarding the number oftimes a consumer viewed an offer before redeeming it, how many times,generally, offers are viewed per month, etc. The details associated withoffer impressions and the offer impression table are discussed below.

In accordance with aspects of the claimed invention(s), a DOM injectionprocess is utilized to effect the dynamic updating of a consumer'sdisplay to include TMOs in the display, as described next in connectionwith FIG. 19B. In this embodiment, the script that effects the injectionor merger of the TMO information is provided from a server associatedwith the OPS (identified as OPS local server 207 in FIG. 19A, alsocalled a “script server”), as a result of calls provided to it from abank web server 219.

FIG. 19B is a sequence diagram illustrating one embodiment of the stepsassociated with injecting matched offers into consumer financialinstitution portals via a DOM injection process 1900a. As shown, theembodiment of the DOM injection process generally comprises three systemcomponents—a client browser (i.e., consumer 103 accessing a financialinstitution portal), a bank web server (i.e., financial institution webserver) 219, and a local server associated with the OPS 207 (i.e., aserver residing behind financial institution firewalls and operativelycoupled to OPS database 307).

At step 1 in FIG. 19B, the consumer 103 initiates a secure, on-linesession with the financial institution 205 via the consumer's webbrowser for purposes of reviewing his or her transactions, managing hisor her accounts, etc. Typically, the consumer will be requesting adisplay of an account history page comprising a list of priortransactions maintained by the consumer's financial institution. At step2, the client browser requests, receives from the financial institutionweb server 219, and renders the consumer's transaction display 2000(discussed below), including the consumer's recent transactionsassociated with a specific account. At step 3, after the consumer'stransactions display web page has been rendered, the client browserrequests and executes a DOM Injection Loader (i.e., a minimal amount ofcode inserted into bank's web services code, discussed previously, whoseprimary purpose is to invoke the operation of an embedded code engineassociated with the browser, such as Javascript).

At step 4, the DOM Injection Loader then requests a DOM Injection Script(i.e., more extensive executable code or script stored within the OPS207 that executes offer insertion or injection functionality, discussedpreviously) via an asynchronous call to the financial institution webserver 219. The call for the injection script typically includes anidentifier of the consumer and a network return pathname (URL) forreturning the script and other information (such as the TMO information)from the OPS to the client machine.

At step 5, the financial institution web server 219 recognizes that theasynchronous call is intended for the OPS (via a reverse proxy 217 orother similar mechanism) as a script server, and redirects the call tothe OPS local server.

At steps 6 and 7, upon receipt of the asynchronous call, the OPS 207acting as a script server transmits a DOM Injection Script back to thebank's web server 219, which then returns the DOM Injection Script tothe client browser (in response to the browser's asynchronous request)via the network return pathname. At step 8, the client browser executesthe DOM Injection Script for purposes of identifying the particularconsumer account being accessed along with the consumer transactionspreviously rendered to the consumer 103 via the transactions (accounthistory) display.

At step 9, after the consumer's account and transactions informationhave been identified, the DOM Injection Script transmits thisinformation to the financial institution web server 219 via anotherasynchronous call, and the web server again redirects the call to theOPS local server (step 10). Stated in other words, the information inthe account history display, which either has been or will be displayedto the consumer by the bank web server, is transmitted to the OPS localserver so that this information can be used to access the matched offertable 1800 (FIG. 18) and determine if any targeted marketing offers areavailable for provision to the consumer.

At step 11, and still referring to FIG. 19B, once the OPS 207 receivesthe asynchronous call redirected from the bank web server, the OPSidentifies and determines which offers should be displayed to theconsumer 103 via the financial institution portal based on theparticular consumer account and the rendered transactions. In order todetermine which offers to transmit back to the bank's web server (andthence to the consumer's browser) for display to a consumer, the OPSsearches the matched offer table 1800 in the OPS database 307 andretrieves offers associated with the consumer's account. Also, based onthe rendered transactions, the OPS makes a determination as to whereoffers should eventually be displayed (i.e., “placed”) on the consumer'stransactions display pursuant to offer placement criteria (typicallydefined by advertisers 213 during campaign generation).

At steps 12, 13, once retrieved, the OPS 207 sends the offers to thefinancial institution web server 219, which in turn transmits the offersto the consumer's browser via the previously supplied network returnpathname. At step 14, upon receipt of the offers, the client browsercontinues execution of the DOM Injection Script and inserts (injects ormerges) the offers into their appropriate display locations on theconsumer's financial institution portal web page in accordance withpredetermined placement information (thereby rendering a display similarto that shown in FIG. 21).

As will be understood by those skilled in the art, the specific stepsshown in FIG. 19B are presented for illustrative purposes only, andother methods for injecting and displaying offers to consumers arepossible according to various embodiments. For example, rather thanusing a DOM injection process, other cross-site scripting mechanisms maybe used. Or, in an alternate embodiment, rather than the client browsermaking the call for offers, the bank web server 219 makes the call tothe local OPS server before the consumer's transactions display web pageis ever rendered. While this server-side approach performs generally thesame functions as a DOM injection approach, many financial institutionsprefer the DOM injection because it enables minimal intrusiveness andrestructuring of a financial institution's internal architecture andsoftware. Further, although the preferred embodiment is described interms of interaction between a client browser (i.e., consumer), afinancial institution web server, and an OPS server, it should beunderstood that various system architectures, script call codes, andother system components may be utilized according to variousembodiments. For example, the computer code used for cross-sitescripting could be stored and executed on a server external to the OPS(assuming that appropriate security mechanisms were employed), or allprocesses could take place within the financial institution computersystem, etc. It will thus be appreciated that virtually any mechanismfor injecting offers into financial institution transactions displaysmay be used in association with embodiments of the present system,assuming those mechanisms comply with financial institution securityprotocols as outlined herein.

FIG. 20 illustrates an exemplary screen shot of a graphical userinterface (GUI) associated with a typical exemplary consumer financialinstitution portal 2000 prior to injection of one or more TMOs into theportal. Through this portal, consumers 103 are able to view and managetheir financial institution accounts, review prior transactions andpurchases 2009, and carry out other banking-related functions. As willbe understood and appreciated, the GUI shown in FIG. 20 is presented forillustrative purposes only, and the actual format and display of eachGUI varies depending on the particular financial institution 205.

As shown, the exemplary portal display 2000 includes account managementtabs 2001, an account number display 2003, a transactions detailssection 2005, and a transactions summary section 2007 for displayingprevious transactions 2009 completed during a given time period. Theforegoing display is an example of an account history page, discussedabove. The representative consumer portal display 2000 also includes therepresentative offer-qualifying purchase (OQP) 115 made at Pizza King(discussed for exemplary purposes in other parts of this disclosure).Because the display 2000 shown in FIG. 20 is representative of aconventional and unmodified display from a financial institution 205, itdoes not include any TMOs.

FIG. 21 illustrates an exemplary screen shot of a GUI associated with aconsumer financial institution portal or display 2100 with multipleexemplary targeted marketing offers (TMOs) 113 displayed thereinaccording to an embodiment of the various inventions described herein.As shown, the portal display 2100 mirrors the display shown in FIG. 20,but with an associated offer 113 a displayed in perceptible associationwith (i.e. close proximity to) its corresponding OQP 115. In the displayshown, the representative Pizza Pub offer 113 a is displayed immediatelyunder the Pizza King OQP 115. Also shown in the portal display 2100 areseveral other TMOs 113 b listed in a side-bar section of the display.According to one embodiment, these TMOs 113 b are associated with anoffer-triggering event (OTE) other than a specific transaction, and aredisplayed based on some criteria associated with the consumer's spendinghabits. Alternatively, the offers 113 b may comprise TMOs specificallylinked to specific, individual transactions of the consumer, but aremerely displayed generally in the portal as opposed to in relativejuxtaposition to the transactions themselves. As will be understood,however, embodiments of the present system 215 may display offers andadvertisements according to various methods, such as directly underlisted transactions, in banner advertisements, pop-up advertisements,etc., and such embodiments are not limited to the type of offer displayshown in FIG. 21. As will also be understood, the offers shown in FIG.21 are a result of the injection process 1900 described previously, inwhich matched offers are retrieved from the matched offer table 1800 andmerged into existing financial institution portal displays to transformthe portal displays.

As mentioned previously, the displayed TMOs 113 remain available forviewing as long as the consumer's OQP 115 is available for review, or aslong as the OTE applies, or as long as dictated by the advertiser 213when the offer or campaign was created. As will be appreciated,consumers may receive multiple offers within display 2100 if many of theconsumer's transactions satisfy one or more TCS's within the system 215.Further, as will be understood, there are circumstances in which a givenconsumer fails to qualify to receive any offers because none of his orher transactions satisfy any offer segment dimensions. In thesecircumstances, the consumer's financial institution portal remainsunchanged, such as that shown in FIG. 20. Additionally, as will beunderstood and appreciated, offers are displayed to consumers 103 viaany viewable portal display, such as those on a mobile device (e.g.,cell phone), laptop computer, desktop computer, or any other similardisplay.

According to another aspect of the disclosed system, targeted marketingoffers (TMOs) may be determined in accordance with different dimensionsof segmentation, and/or successive and dependent segmentation, withdifferent conditions and rewards provided for different but relatedsegments. In this regard, turn now to FIG. 22 for explanation of anexemplary successive segmentation example.

FIG. 22 is a block diagram illustrating the potential matching of threeexemplary offers to consumers 103 associated with three unique targetedconsumer segments (TCS's) based on predefined dimensions associated withthe segments. As will be understood, FIG. 22 is presented forillustrative purposes only, and the specific segments, offers, andsegmentation strategy shown are not intended to limit the scope of thepresent disclosure in any way. As shown, the exemplary advertiser 213(i.e., Pizza Pub) has defined three distinct dimensions 2201, 2203, 2205that, when processed according to advertiser specifications, definethree distinct segments (and thus correspond to three separate potentialoffers 2207, 2209, 2211). In the location dimension 2201, the advertiserhas indicated that in order to qualify for an offer associated with thegiven segment, the transaction must have occurred in California (or,depending on the embodiment, the consumer must live in California,etc.). In the merchant category/merchant name dimension 2203, theadvertiser has indicated that a purchase must have been made with “PizzaKing” in order to qualify to receive an offer. In the spend amountdimension 2205, the advertiser has specified a minimum spend amount of$25.

As shown, the advertiser 213 has constructed the campaign in such a waythat, rather than requiring that all segment dimensions be satisfied, ifa consumer 103 satisfies one of the defined dimensions 2201-2205, butnot the others, then the consumer still receives a TMO associated withthe particular dimension. For example, if a consumer makes a purchase inCalifornia, but the purchase is totally unrelated to Pizza King and wasfor less than $25, the consumer will still receive an offer 2207. Asshown in this specific example, however, the offer 2207 is lesslucrative than the other offers 2209, 2211 because the segmentassociated with the offer is less targeted. However, other offerscreated by other advertisers may have higher value if less targeted. Aswill be understood, the offer value is set by an advertiser as desired,and is in no way specifically tied to targeting. Additionally, in theexample shown, if another consumer satisfies two dimensions, but not athird, then the consumer will also receive an offer 2209 (albeit adifferent offer from the first consumer), and so on.

As shown, if all three dimensions are satisfied (based on the Booleanconstruct “AND”), then the consumer will receive the most lucrativeoffer 2211. As will be understood and appreciated, advertisers 213 arefree to organize and create campaigns, segments, and offers as theydesire. For example, as opposed to the hierarchically segmented campaignrepresented in FIG. 22, an advertiser may define its segments in such away that all segment dimensions must be satisfied by a consumertransaction before an offer is presented to the consumer. Generally,embodiments of the present system enable advertisers to constructcampaigns according to various Boolean operators (i.e., AND, OR,If/Then, etc.), hierarchical dependencies, and other strategies as willoccur to one of ordinary skill in the art.

As shown, in one embodiment, offers are different and generally becomemore lucrative as the segment narrows (i.e., as more segment dimensionsare satisfied by a consumer transaction), as it is typically morevaluable to obtain the business of consumers that have higherpropensities to buy advertiser-related items (e.g., pizzas), especiallyif those consumers are customers of an advertiser competitor 101. Forexample, if a given consumer rarely or never buys pizzas (based on priorspending habits), then providing offers to these customers generally haslittle value to an advertiser 213 that sells pizzas. Further, anotherreason why offers generally become more valuable as the segment narrowsis that providing valuable offers to large segments of consumers canbecome cost prohibitive to advertisers. However, as will be understood,advertisers are free to organize offers and segments as they see fit,and offers do not have to become more lucrative as a segment narrows. Infact, some advertisers may choose to deliver high value offers to largesegments of consumers in the hopes of engendering a large volume ofbusiness.

Offer Realization/Redemption

FIG. 23 is a flowchart illustrating an embodiment of acomputer-implemented redemption process 2300 within the OPS 207 fordetermining whether one or more offers have been redeemed by a consumer,according to one aspect of disclosure. The embodiment of the redemptionprocess shown in FIG. 23 also includes the functions of creditingredemptions to each respective financial institution's consumers andproviding reporting and billing functions related to redemptions foradvertisers. The redemption process 2300 is typically carried out in aparticular machine, in this case an OPS 207 associated with a particularfinancial institution that employs aspects of the disclosed system.

Starting at step 2301, an OPS 207 monitors for incoming de-identifiedconsumer transaction data from its respective associated financialinstitution. If no data is received, then the process 2300 loops to step2301, and the OPS again monitors for incoming data (step 2303). Just aswith other recurring processes discussed herein, steps 2301, 2303 arerepeated either continuously or on a recurring, periodic basis.

If de-identified consumer transaction data is received, then the data isstored within the de-identified consumer transaction table 1700 withinthe OPS database 307 (step 2305). If any of the merchant names in thede-identified consumer transaction data cannot be identified, the namesare transmitted to the OMS for merchant identification (see FIG. 5 andassociated discussion) before any redemptions are determined for thespecific transactions. Next, the OPS accesses the matched offer table1800 from within the OPS database 307, compares the de-identifiedconsumer transaction data (using the validated merchant name(s)) to thedata in the matched offer table, and determines whether one or morepreviously-placed TMOs have been redeemed by one or more consumers(steps 2307, 2309). In one embodiment, step 2309 is performed by apredetermined algorithm that compares each transaction received from thefinancial institution (for example, a list of transactions such as thoseshown in table 1700) for a particular consumer with that consumer'spreviously-placed offer(s) in the matched offer table 1800 to determineif any of the offer criteria of the offers displayed to the consumerhave been satisfied. As described elsewhere herein, each offer generallydefines one or more offer criteria necessary to redeem the offer, suchas “$10 off any purchases of $25 or more made at a Pizza Pub in June”.Thus, if one of the transactions received from the financial institutionmeets the defined criteria of an offer associated with the givenconsumer's account, then the offer is defined as redeemed. In oneembodiment, each consumer's matched offers are stored in a separatematched offer table or file 1800 to simplify the comparison process ofstep 2309 (as well as the previously-discussed injection process 1900).

If no offers are determined redeemed (based on the results of step2309), then the redemption process 2300 for the particular set ofde-identified consumer transaction data is ended (step 2311). If,however, an offer is determined redeemed, then OPS utilizes apre-determined conversion algorithm to automatically convert theredemption value, as stipulated by the originally-presented TMO 113,into the appropriate rewards type (if different from cash) for theaccount associated with the RQP 117 in which the offer was redeemed(step 2313). For example, a financial institution 205 may dictate that$1.00 in offer value is equivalent to 3 airline miles. Thus, if an offervalue of $10.00 was redeemed, the consumer account will receive 30airline miles. Once the reward value has been converted (if necessary),the redemption is recorded by the OPS 207 in an offer redemption table2500 (see FIG. 25 and its associated discussion) (step 2315) in the OPSdatabase 307. Depending on the particular embodiment, details associatedwith the RQP are recorded, such as the time and/or date of the RQP, thespecific advertiser location at which the RQP occurred, and othersimilar data (see exemplary data structure 2500). In one embodiment, theOPS will provide its associated financial institution(s) with a reportor notification of all RQPs having occurred within a defined period oftime, which the financial institution will in turn utilize to issueoffer redemption payment(s) to the appropriate consumer account(s) (step2317).

In general, the financial institution 205 is directly reimbursed for thevalue of each reward paid to a consumer by the TMS, which in turnreceives payment from advertisers for all redeemed offers..Additionally, in one embodiment, an operator of the TMS chargesadvertisers a fee to create and execute targeted marketing campaigns.When a consumer 103 subsequently logs in to his or her financialinstitution portal 2100 to view his or her account activity, the OPS 207performs a process similar to the injection process 1900 shown in FIG.19, although rather than merging matched offers into the portal display,the OPS injects a notice or icon 119 indicating that the consumer hasreceived an ORP 225 (see FIG. 27 and associated discussion).

As will be understood and appreciated by one having ordinary skill inthe art, in order to redeem offers according to discussed embodiments ofthe present system 215, a consumer 103 is not required to cut out anduse any coupons, print out any advertisements, enter in any promotioncodes, etc. (although, an advertiser can mandate such coupon usage, ifdesired). Generally, all that is required is for a consumer to make aRQP 117 using a payment mechanism associated with the account in whichthe original OQP 115 was made. Once a consumer makes such a RQP, theassociated redemption payment is automatically issued to the consumer'saccount, as described herein.

FIG. 24 is an exemplary offer impression table 2400 illustratingrecorded offers that have been viewed by consumers 103 based on consumerlog-ins to financial institution portals. FIG. 25 is an exemplary offerredemption table 2500 illustrating offers that have been redeemed byconsumers based on redemption-qualifying purchases 117. As will beunderstood, tables 2400, 2500 are presented for illustrative purposesonly, and embodiments of the present system 215 are not limited to useof the specific data tables shown. Each of the tables 2400, 2500comprises a plurality of entries representing offer impressions andoffer redemptions, respectively, each entry comprising a plurality ofdata categories or fields.

As shown, the each entry in the tables 2400, 2500 includes four datacategories or fields: offer identifier (ID) 2401, 2501, account globalunique identifier (GUID) 2403, 2503, date (either of impression orredemption) 2405, 2505, and time (either of impression or redemption)2407, 2507. As will be understood, however, the data categories or filesare not limited to the fields shown, and other embodiments includeadditional fields as will occur to one of ordinary skill in the art.Additionally, in one embodiment, not all data shown in tables 2400, 2500is recorded (e.g., time of impression or redemption is not necessarilyrecorded). As will also be understood, although only five data entriesare shown in table 2400 (i.e., entries corresponding to GUIDs 12932,49830, etc.), and three data entries are shown in table 2500 (i.e.,entries corresponding to GUIDs 12932, 80204, etc.), actual data tablesconstructed in accordance with aspects of the present system may includea virtually unlimited number of entries corresponding to a plurality ofimpressions and/or redemptions recorded by embodiments of the presentTMS 215.

As shown, the offer ID fields 2401, 2501 and account GUID fields 2403,2503 correspond to similar fields and data entries shown and discussedpreviously in conjunction with FIGS. 13, 16-18, etc. These fieldsidentify the particular TMOs that are either viewed or redeemed byconsumers, as well as the corresponding consumer accounts associatedwith the offers. The date fields 2405, 2505 and time fields 2407, 2507indicate the specific dates and times that offers are viewed and/orredeemed, respectively. Again, the data fields referred to herein arenot limited by the specific fields shown in FIGS. 24 and 25, and otherdata items are contemplated, such as the number of times each offer isviewed (i.e., number of impressions), specific advertiser location atwhich an offer is redeemed, the spend amount associated with eachredemption, and other similar data fields. Generally, the data shown intables 2400, 2500 is utilized for purposes of issuing redemptions toconsumers. Further, according to one embodiment, the data shown intables 2400, 2500 is aggregated (i.e., see campaign results table 2600),and used for reporting campaign performance to advertisers.Additionally, as shown, the representative impression and redemption2409, 2509 correspond to the Pizza Pub/Pizza King example referenced inother parts of this disclosure.

FIG. 26 is an exemplary campaign results table 2600 illustratingaggregated offer performance data (i.e., offer impressions andredemptions). The aggregated offer performance data comprises aplurality of individual entries of results for a targeted marketingoffer, each entry including a plurality of data fields. As shown, eachentry in the table 2600 includes three data categories or fields: offeridentifier (ID) 2601, offer impressions 2603, and offer redemptions2605. These fields thus relate specific results of offer impressions andoffer redemptions with a particular identified targeted marketing offer,within a campaign as delimited by means not shown, such as a particularreporting period, or for a particular advertiser, etc. As will beunderstood, however, the data categories or files are not limited to thefields shown, and other embodiments include additional fields as willoccur to one of ordinary skill in the art. As will also be understood,although only three data entries are shown in table 2600 (i.e., entriescorresponding to offer IDs 99999, 40568, etc.), actual data tablesconstructed in accordance with aspects of the present system may includea virtually unlimited number of entries corresponding to campaignresults data 301 recorded by embodiments of the present TMS 215.

As shown, offer impressions field 2603 illustrates exemplary, aggregatedoffer impressions associated with specific offers. Offer redemptionsfield 2605 illustrates exemplary, aggregated offer redemptionsassociated with specific offers. According to one embodiment, this datais aggregated within each OPS 207 and transmitted to the OMS 211 forreporting to advertisers 213. As will be understood, various other typesof data is included in the campaign results table 2600 according tovarious embodiments, including the number of times an offer is “clicked”(i.e., accessed with a mouse or cursor) for additional information by aconsumer within a financial institution portal, information entered by aconsumer into a data entry field associated with an offer, etc.Additionally, as shown, the representative results entry 2607corresponds to the Pizza Pub/Pizza King example referenced in otherparts of this disclosure.

FIG. 27 illustrates an exemplary screen shot of a GUI associated with aconsumer financial institution portal 2700 with targeted marketingoffers (TMOs) 113, a redemption-qualifying purchase (RQP) 117, and a RQPicon 119 displayed therein according to an embodiment of the present TMS215. As shown, the portal display 2700 mirrors the display shown in FIG.21, but with the associated RQP and RQP icon indicated accordingly. Theexemplary RQP 117 satisfies the criteria defined in the originalexemplary TMO 113 a (i.e., purchase made at a Pizza Pub, in June, formore than $25), and thus the representative consumer account shown iscredited the $10 dictated in the offer (see FIG. 28 for exemplaryrewards page) as constituting an offer redemption payment (ORP) 225.

As mentioned previously, because the RQP is carried out using a paymentmechanism associated with the account with which the original OQP wasmade (as evidenced by the fact that the RQP is listed on the sameaccount summary web page as the OQP), the OPS 207 automaticallyrecognizes the RQP and instructs the financial institution 205 to pay anassociated redemption payment or reward to the consumer 103. Accordingto one embodiment of the present system 215, rewards (i.e., ORPs 225)are indicated on a separate rewards page (e.g., FIG. 28). In otherembodiments, however, ORPs are indicated in the amount column 2701 of atransaction summary 1707 (e.g., the amount for the representative RQP117 would read $18.93 instead of $28.93), or listed underneath the RQPitself, or indicated via some other similar display mechanism.

As shown in FIG. 27, a RQP icon 119 is provided in relativejuxtaposition with the RQP 117, thus indicating that the giventransaction is in fact a RQP, and that an associated ORP 225 has been orwill be issued to the particular consumer's account. The exemplary RQPicon is shown in FIG. 27 as a circle with a dollar sign containedtherein, but other types of icons and icon images are contemplatedaccording to various embodiments of the present system, and can beconfigured uniquely for each financial institution. Accordingly, aspectsof the present system are not limited by the specific example icon ordisplay format shown. Further, in the embodiment shown, when a consumer103 hovers a cursor over the RQP icon 119, or clicks or otherwiseinteracts with the icon via the financial institution portal 2700, apop-up redemption message 2703 is displayed to the consumer thanking theconsumer for the purchase 117 and describing the savings or reward thatwas issued to the consumer. As will be understood and appreciated, theicon 119 and redemption message 2703 are presented for illustrativepurposes only, and the formats and overall use of these elements mayvary according to various embodiments of the present system. Further,some embodiments do not use a RQP icon 119 or a redemption message 2703,and merely issue automatic redemptions or rewards to consumers'accounts. Additionally, for TMOs that do not present possibleredemptions, and are merely advertisements for a particular advertiser,no ORP is issued and no RQP icon is shown, as there is no potentialredemption available with the TMO.

FIG. 28 illustrates an exemplary screen shot of a GUI associated with aconsumer financial institution portal displaying a representativerewards page 2800 according to an embodiment of the present TMS 215. Aswill be understood and appreciated, the rewards page 2800 may beincorporated into a financial institution's existing, conventionalaccount rewards page, or may comprise a separate page only displayingrewards associated with embodiments of the TMS 215. As will also beunderstood, regardless of the format of the rewards page, or any otherexemplary screen shot or web page discussed herein, each page integratesseamlessly and adapts to the particular online format of each respectivefinancial institution 205.

As shown, rewards tab 2001 is selected, indicating a rewards displaypage 2800 within the consumer financial institution portal. The rewardspage 2800 includes a rewards summary section 2801 listing recent ORPs225 issued to the particular consumer 103. Exemplary reward 2803indicates the $10 cash back received in association with the Pizza Pubtransaction (shown and discussed previously). Although the redeemedrewards 225 are shown in FIG. 28 as credits or cash back, other aspectsof the present system incorporate other forms of rewards, such asairline miles, points, etc. (discussed previously). In one embodiment,the consumer 103 has the option of redeeming the displayed rewards(i.e., receiving a paper check or a credit to one of the consumer'saccounts). In another embodiment, the rewards are automatically issuedto the consumer's account in the form of a credit or otherwise.Typically, the rewards associated with TMOs according to embodiments ofthe present TMS 215 are handled in a similar manner as conventionalrewards programs run by financial institutions, and, generally, eachfinancial institution has discretion as to how rewards are issued.

Similar to the rewards page 2800 shown in FIG. 28, some embodiments ofthe present system 215 incorporate an offer(s) detail page (not shown)that lists or displays all pending and/or past offers presented to agiven consumer 103, as well as the status of those offers (i.e.,available, redeemed, expired, etc.). In the offer(s) detail page, aconsumer has the ability to view his or her TMOs 113 collectively in acentralized location and across many accounts rather than separatelyunder each account page and OQP 115. An offer(s) detail page isespecially useful in circumstances in which a consumer has manytransactions associated with a given account, or has many accounts withone financial institution 205. By collecting the offers on one page, theconsumer is able to conveniently and quickly review all available offersassociated with his or her financial institution accounts, as well askeep track of prior redemptions.

As mentioned previously, as consumers 103 view and/or redeem offers,these offer impressions and/or redemptions are recorded by each OPS 207,aggregated, and subsequently transmitted to the OMS 211 for reportingand billing purposes. Advertisers 213 are able to view such campaignresults data 301 and assess the overall success (i.e., performance) oftheir advertising campaigns. Through this data, advertisers are able todetermine which aspects of campaigns and offers generate high responserates and consumer interaction, and which do not. This information isutilized to shape future campaigns and offers in highly targeted ways toproduce maximum consumer response. Again, this highly valuable form ofmarketing is based on consumer spending habits, yet also accomplishedwithout disclosure of confidential or private consumer information toany outside parties.

FIG. 29 illustrates an exemplary OMS hardware architecture 2900 uponwhich an embodiment of the OMS may be implemented as herein described.FIG. 30 illustrates an exemplary OPS hardware architecture 3000 uponwhich an embodiment of the OPS may be implemented as herein described.As shown in FIGS. 29-30 and described previously herein, the hardwarecomponents of the OMS 211 and OPS 207 are specifically designed to carryout the particular functions and processes of the TMS 215 (i.e., theyare particular machines). As will be understood and appreciated, thehardware representations 2900, 3000 are shown for illustrative purposesonly, and other hardware variations will occur to those of ordinaryskill in the art. Further, the hardware implementations shown in FIGS.29-30 do not necessarily include representations of detailed hardwareconnections via firewall(s) 330, reverse proxies 217, and other systemarchitecture components shown and described previously herein.

As shown, both the OMS and OPS include a bus 2901, 3001 or othercommunication mechanism for communicating information, and one or moreprocessors 2903, 3003 coupled with the bus for processing information.The OMS and OPS each also include a main memory 2905, 3005, such as arandom access memory (RAM) or other similar dynamic storage device,coupled to the bus 2901, 3001 for storing instructions and informationto be executed by the processor(s) 2903, 3003. In addition, main memory2905, 3005 may be used for storing temporary variables or otherintermediate information during execution of instructions to be executedby the processor(s). As shown, the OMS and OPS both include a read onlymemory (ROM) 2907, 3007 or other similar static storage device coupledto the bus for storing static information and instructions for theprocessor(s). Also included within the OMS and OPS are OMS database 305and OPS database 307, respectively, which are coupled to theirrespective buses and used for storage and retrieval of various types ofsystem data as previously described. In one embodiment, as shownpreviously in FIG. 3, the OPS database 307 (and database server) resideseparate and apart from an OPS web server, such that the OPS databaseresides behind one or more additional financial institution firewalls330.

The OMS and OPS hardware systems 2900, 3000, respectively, both includea communication interface 2909, 3009, coupled to the communication bus2901, 3001, which provide two-way data communication coupling to anetwork link 2911, 3011 that is connected to a local area network (LAN)2913, 3013. The communication interface 2909, 3009 generally comprisesan Ethernet or similar network interface card, a digital subscriber line(DSL), or other similar interface. The network link 2911, 3011 maycomprise a wireless link, hard-wired link, or other similar link.Additionally, for ease of reference, firewall(s), reverse proxies 217,DMZ(s), and other ancillary components are not shown in FIGS. 29-30, butit will be understood that these components comprise a part of theoverall hardware architecture of embodiments of the present system.

For the embodiment of the OMS 211 shown in FIG. 29, the network linkprovides data communication through the LAN 2913 to the OMS advertiserportal 900 and each OPS 207 (via the Internet 209), and the systemoperator management portal 2915. Thus, all information transmitted toand from the OPS, or advertisers via the OMS advertiser portal, orsystem operators, is transmitted via the communication link 2911. Thesystem operator management portal 2915 provides access by a systemoperator or manager to the overall targeted marketing system (TMS) 215.According to various embodiments and as will be understood, the systemoperator manages system performance, predefines system parameters,updates system software, and provides a host of other system managementfunctions. For the embodiment of the OPS 207 shown in FIG. 30, thenetwork link 3011 provides data communication through the LAN 3013 tothe OMS 211 (via the Internet 209) and a respective financialinstitution web server 219 (and further to a financial institutiontransaction processor 220, not shown). Again, the hardware componentsand connections illustrated in FIGS. 29-30 are presented forillustrative purposes only, and other system configurations are possibleaccording to various embodiments of the present inventions.

The foregoing description of the exemplary embodiments has beenpresented only for the purposes of illustration and description and isnot intended to be exhaustive or to limit the inventions to the preciseforms disclosed. Many modifications and variations are possible in lightof the above teaching.

The embodiments were chosen and described in order to explain theprinciples of the inventions and their practical application so as toenable others skilled in the art to utilize the inventions and variousembodiments and with various modifications as are suited to theparticular use contemplated. Alternative embodiments will becomeapparent to those skilled in the art to which the present inventionspertain without departing from their spirit and scope. Accordingly, thescope of the present inventions is defined by the appended claims ratherthan the foregoing description and the exemplary embodiments describedtherein.

What is claimed is:
 1. A targeted marketing system operative to delivera targeted marketing offer to a consumer of a financial institution viaan online portal associated with a financial institution computersystem, the online portal operative to provide a display of a consumer'sfinancial transactions during a viewing session, comprising: an offermanagement system operative for receiving input from an advertiserdefining an offer qualifying transaction corresponding to a targetedmarketing offer to be provided to a consumer of the financialinstitution in response to the identification of at least one financialtransaction by the consumer corresponding to the offer qualifyingtransaction, and for delivering campaign data corresponding to thetargeted marketing offer and to the offer qualifying transaction as anoutput to an offer placement system; an offer placement system coupledfor secure communication with the financial institution computer systemto receive and store the campaign data from the offer management system,the offer placement computer system: identifying the at least onefinancial transaction corresponding to the offer qualifying transactionfrom information received from the financial institution computer systemrepresenting financial transactions of the consumer displayed on anelectronic display within the online portal; and in response toidentifying the at least one financial transaction corresponding to theoffer qualifying transaction, retrieving the targeted marketing offerfrom a database operatively connected to the offer placement computersystem, and providing the targeted marketing offer and predeterminedplacement information for placing the targeted marketing offer withinthe display of the financial transactions to the financial institutioncomputer system; and whereby, in response to receiving the targetedmarketing offer, the financial institution computer system modifies theelectronic display by inserting the targeted marketing offer into thedisplay of the financial transactions within the online portal accordingto the predetermined placement information.
 2. The system of claim 1,wherein the at least one financial transaction is reflected intransaction data maintained by the financial institution computersystem.
 3. The system of claim 2, wherein the campaign data includesinformation corresponding to the offer qualifying transaction, andwherein the offer placement system is operative to compare the offerqualifying transaction information in the campaign data to transactiondata of the financial institution corresponding to transactionsconducted by the consumer to identify a particular offer qualifyingtransaction conducted by the consumer.
 4. The system of claim 3, whereinthe offer placement system is operative to display the targetedmarketing offer to the consumer in association with the display ofinformation corresponding to the particular offer qualifying transactionprovided by the online portal.
 5. The system of claim 2, wherein thedelivery of the targeted marketing offer information to the consumercomprises the display of predetermined offer display information inassociation with the display of information corresponding to the offerqualifying transaction.
 6. The system of claim 5, wherein thepredetermined offer display information comprises one or more of thefollowing data items: offer text information, offer image information,reward amount, reward type, date(s) of offer.
 7. The system of claim 5,wherein the predetermined offer display information is displayedadjacent to information of the offer qualifying transaction.
 8. Thesystem of claim 7, wherein the predetermined offer display informationis displayed immediately below the offer qualifying transaction on alist of the consumer's transactions.
 9. The system of claim 7, whereinthe predetermined offer display information is displayed in a field innearby proximity to the offer qualifying transaction on a list of theconsumer's transactions.
 10. The system of claim 1, wherein the at leastone financial transaction is a group of transactions conducted by theconsumer that collectively satisfy predetermined criteria defined by theadvertiser for delivery of the targeted marketing offer to the consumer.11. The system of claim 1, wherein the offer placement system isphysically co-located with the financial institution computer systemassociated with the financial institution and utilizes network securityprotections of the financial institution, and receives de-identifiedtransaction data from a transaction system associated with the financialinstitution computer system.
 12. The system of claim 1, wherein theoffer placement system is one of a plurality of offer placement systemscoupled for secure communication with the financial institution computersystem.
 13. The system of claim 1, wherein the offer placement systemdetermines the predetermined placement information pursuant to thecampaign data received from the offer management system.
 14. Acomputer-implemented method for delivering a targeted marketing offer toa consumer of a financial institution via an online portal associatedwith a financial institution computer system, the online portaloperative to provide a display of a consumer's financial transactionsduring a viewing session, comprising the steps of: receiving, at anoffer management computer system, input from an advertiser defining anoffer qualifying transaction corresponding to a targeted marketing offerto be provided to a consumer of the financial institution in response tothe identification of at least one financial transaction by the consumercorresponding to the offer qualifying transaction; generating, at theoffer management computer system, campaign data corresponding to thetargeted marketing offer and to the offer qualifying transaction; theoffer management computer system providing the campaign data to an offerplacement computer system operatively connected to the offer managementcomputer system and coupled for secure communication with the financialinstitution computer system for use in connection with operations of theonline portal of the financial institution; identifying, by the offerplacement computer system, the at least one financial transactioncorresponding to the offer qualifying transaction from informationreceived by the offer placement computer system from the financialinstitution computer system, the information from the financialinstitution computer system representing financial transactions of theconsumer displayed on an electronic display with the online portal; andin response to identifying the at least one financial transactioncorresponding to the offer qualifying transaction, retrieving thetargeted marketing offer from a database operatively connected to theoffer placement computer system, and providing the targeted marketingoffer and predetermined placement information for placing the targetedmarketing offer within the display of the financial transactions to thefinancial institution computer system; and whereby, in response toreceiving the targeted marketing offer, the financial institutioncomputer system modifies the electronic display by inserting thetargeted marketing offer into the display of the financial transactionswithin the online portal according to the predetermined placementinformation.
 15. The method of claim 14, wherein the at least onefinancial transaction is reflected in transaction data maintained by thefinancial institution.
 16. The method of claim 15, wherein the campaigndata includes information corresponding to the offer qualifyingtransaction, and further comprising the step of comparing the offerqualifying transaction information in the campaign data to transactiondata of the financial institution corresponding to transactionsconducted by the consumer to identify a particular offer qualifyingtransaction conducted by the consumer.
 17. The method of claim 16,further comprising the step of displaying the targeted marketing offerto the consumer in association with the display of informationcorresponding to the particular offer qualifying transaction provided bythe online portal.
 18. The method of claim 15, wherein the display ofselected targeted marketing offer information comprises the display ofpredetermined offer display information in association with the displayof information corresponding to the offer qualifying transaction. 19.The method of claim 18, wherein the predetermined offer displayinformation comprises one or more of the following data items: offertext information, offer image information, reward amount, reward type,date(s) of offer.
 20. The method of claim 18, wherein the predeterminedoffer display information is displayed adjacent to information of theoffer qualifying transaction.
 21. The method of claim 18, wherein thepredetermined offer display information is displayed immediately belowthe offer qualifying transaction on a list of the consumer'stransactions.
 22. The method of claim 18, wherein the predeterminedoffer display information is displayed in a field in nearby proximity tothe offer qualifying transaction on a list of the consumer'stransactions.
 23. The method of claim 14, wherein the at least onefinancial transaction is a group of transactions conducted by theconsumer that collectively satisfy predetermined criteria defined by theadvertiser for delivery of information corresponding to the targetedmarketing offer to the consumer.
 24. The method of claim 14, wherein theoffer placement system is physically co-located with the financialinstitution computer system associated with the financial institutionand utilizes network security protections of the financial institution,and receives de-identified transaction data from a transaction systemassociated with the financial institution computer system.
 25. Themethod of claim 14, wherein the offer placement system is one of aplurality of offer placement systems coupled for secure communicationwith the financial institution computer system.
 26. The method of claim14, wherein the offer placement system determines the predeterminedplacement information pursuant to the campaign data received from theoffer management system.